How to Configure Symfony to Work behind a Load Balancer or a Reverse Proxy

How to Configure Symfony to Work behind a Load Balancer or a Reverse Proxy

When you deploy your application, you may be behind a load balancer (e.g. an AWS Elastic Load Balancing) or a reverse proxy (e.g. Varnish for caching).

For the most part, this doesn’t cause any problems with Symfony. But, when a request passes through a proxy, certain request information is sent using either the standard Forwarded header or X-Forwarded-* headers. For example, instead of reading the REMOTE_ADDR header (which will now be the IP address of your reverse proxy), the user’s true IP will be stored in a standard Forwarded: for="..." header or a X-Forwarded-For header.

If you don’t configure Symfony to look for these headers, you’ll get incorrect information about the client’s IP address, whether or not the client is connecting via HTTPS, the client’s port and the hostname being requested.

Solution: setTrustedProxies()

To fix this, you need to tell Symfony which reverse proxy IP addresses to trust and what headers your reverse proxy uses to send information:

  • YAML
    1
    2
    3
    4
    5
    6
    7
    8
    9
    # config/packages/framework.yaml
    framework:
        # ...
        # the IP address (or range) of your proxy
        trusted_proxies: '192.0.0.1,10.0.0.0/8'
        # trust *all* "X-Forwarded-*" headers
        trusted_headers: ['x-forwarded-for', 'x-forwarded-host', 'x-forwarded-proto', 'x-forwarded-port']
        # or, if your proxy instead uses the "Forwarded" header
        trusted_headers: ['forwarded']
    
  • XML
     1
     2
     3
     4
     5
     6
     7
     8
     9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    24
    <!-- config/packages/framework.xml -->
    <?xml version="1.0" encoding="UTF-8" ?>
    <container xmlns="http://symfony.com/schema/dic/services"
        xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
        xmlns:framework="http://symfony.com/schema/dic/symfony"
        xsi:schemaLocation="http://symfony.com/schema/dic/services
            https://symfony.com/schema/dic/services/services-1.0.xsd
            http://symfony.com/schema/dic/symfony
            https://symfony.com/schema/dic/symfony/symfony-1.0.xsd">
    
        <framework:config>
            <!-- the IP address (or range) of your proxy -->
            <framework:trusted-proxies>192.0.0.1,10.0.0.0/8</framework:trusted-proxies>
    
            <!-- trust *all* "X-Forwarded-*" headers -->
            <framework:trusted-header>x-forwarded-for</framework:trusted-header>
            <framework:trusted-header>x-forwarded-host</framework:trusted-header>
            <framework:trusted-header>x-forwarded-proto</framework:trusted-header>
            <framework:trusted-header>x-forwarded-port</framework:trusted-header>
    
            <!-- or, if your proxy instead uses the "Forwarded" header -->
            <framework:trusted-header>forwarded</framework:trusted-header>
        </framework:config>
    </container>
    
  • PHP
     1
     2
     3
     4
     5
     6
     7
     8
     9
    10
    11
    // config/packages/framework.php
    use Symfony\Component\HttpFoundation\Request;
    
    $container->loadFromExtension('framework', [
        // the IP address (or range) of your proxy
        'trusted_proxies' => '192.0.0.1,10.0.0.0/8',
        // trust *all* "X-Forwarded-*" headers (the ! prefix means to not trust those headers)
        'trusted_headers' => ['x-forwarded-for', 'x-forwarded-host', 'x-forwarded-proto', 'x-forwarded-port'],
        // or, if your proxy instead uses the "Forwarded" header
        'trusted_headers' => ['forwarded'],
    ]);
    

Deprecated since version 5.2: In previous Symfony versions, the above example used HEADER_X_FORWARDED_ALL to trust all “X-Forwarded-” headers, but that constant is deprecated since Symfony 5.2 in favor of the individual HEADER_X_FORWARDED_* constants.

Caution

Enabling the Request::HEADER_X_FORWARDED_HOST option exposes the application to HTTP Host header attacks. Make sure the proxy really sends an x-forwarded-host header.

The Request object has several Request::HEADER_* constants that control exactly which headers from your reverse proxy are trusted. The argument is a bit field, so you can also pass your own value (e.g. 0b00110).

New in version 5.2: The feature to configure trusted proxies and headers with trusted_proxies and trusted_headers options was introduced in Symfony 5.2. In earlier Symfony versions you needed to use the Request::setTrustedProxies() method in the public/index.php file.

Caution

The “trusted proxies” feature does not work as expected when using the nginx realip module. Disable that module when serving Symfony applications.

But what if the IP of my Reverse Proxy Changes Constantly!

Some reverse proxies (like AWS Elastic Load Balancing) don’t have a static IP address or even a range that you can target with the CIDR notation. In this case, you’ll need to - very carefully - trust all proxies.

  1. Configure your web server(s) to not respond to traffic from any clients other than your load balancers. For AWS, this can be done with security groups.

  2. Once you’ve guaranteed that traffic will only come from your trusted reverse proxies, configure Symfony to always trust incoming request:

    1
    2
    3
    4
    5
    6
    # config/packages/framework.yaml
    framework:
        # ...
        # trust *all* requests (the 'REMOTE_ADDR' string is replaced at
        # run time by $_SERVER['REMOTE_ADDR'])
        trusted_proxies: '127.0.0.1,REMOTE_ADDR'
    

That’s it! It’s critical that you prevent traffic from all non-trusted sources. If you allow outside traffic, they could “spoof” their true IP address and other information.

Tip

In applications using Symfony Flex you can set the TRUSTED_PROXIES env var:

1
2
# .env
TRUSTED_PROXIES=127.0.0.1,REMOTE_ADDR
1
2
3
4
# config/packages/framework.yaml
framework:
    # ...
    trusted_proxies: '%env(TRUSTED_PROXIES)%'

If you are also using a reverse proxy on top of your load balancer (e.g. CloudFront), calling $request->server->get('REMOTE_ADDR') won’t be enough, as it will only trust the node sitting directly above your application (in this case your load balancer). You also need to append the IP addresses or ranges of any additional proxy (e.g. CloudFront IP ranges) to the array of trusted proxies.

Custom Headers When Using a Reverse Proxy

Some reverse proxies (like CloudFront with CloudFront-Forwarded-Proto) may force you to use a custom header. For instance you have Custom-Forwarded-Proto instead of X-Forwarded-Proto.

In this case, you’ll need to set the header X-Forwarded-Proto with the value of Custom-Forwarded-Proto early enough in your application, i.e. before handling the request:

// public/index.php

// ...
$_SERVER['HTTP_X_FORWARDED_PROTO'] = $_SERVER['HTTP_CUSTOM_FORWARDED_PROTO'];
// ...
$response = $kernel->handle($request);

This work, including the code samples, is licensed under a Creative Commons BY-SA 3.0 license.