Getting a User's IP Address and the Application's Domain Name in Laravel

Getting a visitor's IP address and getting the application's own current domain name are both single-line lookups in Laravel — the IP address specifically has a genuine gotcha worth knowing about when the app sits behind a proxy or load balancer.

Getting the visitor's IP address

$ip = $request->ip();

The proxy gotcha: an incorrect IP behind a load balancer

// Without trusting the proxy, this can return the load balancer's own IP,
// not the actual visitor's IP
$ip = $request->ip();

Following the same underlying issue as the HTTPS-scheme detection problem covered elsewhere on this site, a request passing through a reverse proxy or load balancer arrives at Laravel with the proxy's own IP as the connection source — the real visitor's IP is instead carried in an X-Forwarded-For header, which Laravel only reads correctly once the proxy is explicitly configured as trusted.

Configuring trusted proxies to fix this

// bootstrap/app.php
->withMiddleware(function (Middleware $middleware) {
    $middleware->trustProxies(at: '*');
})

Once the proxy is trusted, $request->ip() correctly resolves to the actual visitor's real IP address by reading it from the appropriate forwarded header, rather than returning the proxy's own address every single time regardless of who the actual visitor is.

Getting every IP in the forwarding chain

$allIps = $request->ips(); // array, most trusted first

When a request passes through multiple proxies (a CDN, then a load balancer, for instance), ips() returns the full chain — genuinely useful for debugging a proxy configuration issue, though ip() alone is what most application code actually needs.

Getting the application's own domain name

$domain = request()->getHost(); // e.g. "example.com"
$fullUrl = request()->getSchemeAndHttpHost(); // e.g. "https://example.com"

Getting the configured application URL instead of the request-derived one

$appUrl = config('app.url'); // reads directly from .env's APP_URL

config('app.url') reads the explicitly configured value rather than deriving it from the current request — genuinely more reliable in a context with no active HTTP request at all (a scheduled command, a queued job), where request()->getHost() simply isn't available since there's no incoming request to read it from.

A practical use case: logging IP addresses for a rate limiter or audit trail

ActivityLog::create([
    'user_id' => auth()->id(),
    'ip_address' => $request->ip(),
    'action' => 'login',
]);

Logging a user's IP alongside sensitive actions (login, password change) is a common and useful security practice — worth pairing with awareness of relevant privacy regulations, since an IP address is generally considered personal data under regulations like GDPR and shouldn't be retained indefinitely without a genuine, documented reason.

Why geolocating an IP address needs a separate external service

Laravel has no built-in IP geolocation capability — determining a visitor's approximate country or city from their IP address requires a separate service or database (like MaxMind's GeoIP or a similar API), since Laravel's own IP-reading methods return only the raw address string itself, with no location data attached.