In /core/lib/Drupal/Core/DrupalKernal.php the $base_root shows incorrect value:

Line 1113 protected function initializeRequestGlobals(Request $request) { global $base_url; // Set and derived from $base_url by this function. global $base_path, $base_root; global $base_secure_url, $base_insecure_url;

// Create base URL.
$base_root = $request->getSchemeAndHttpHost();

The value the $base_root is showing is the machine name, not the requested url. Specifically, the $base_root value is like: https://machinename.windows.domain.com instead of the request url like: https://ourcompany.com

I've searched the database, exported configs, and all files in the installation for the "machinename", but the only place it exists is on the windows server as "my computer" name.

Our environment is set up with an AWS loadbalancer, AWS cert on loadbalancer, that relays traffic to the windows EC2 server.

Running very recent Apache, PHP and Drupal 8.7.14. Running updated modules using composer. I don't think this is a bug.

The problems this causes is that when there is a redirect url, or self reference, such as in the webform or workflow module, you get an error because the machinename url is not accessible externally.

I wrote code to hack DrupalKernel.php that changes the $base_root using str_replace(). Also did this to RedirectResponseSubscriber.php, which FIXES my problem. But, this is the worst kind of hack programming.

Is there a way to force symfony $request->getSchemeAndHttpHost() to give my proper url? Maybe a setting I missed?

I've been very reluctant to post this question because of the obvious criticism it can draw. I've seen a lot of "working as intended" responses around $base_url issues which don't help my case.

  • Maybe a setting I missed? Check "Reverse Proxy Configuration" in settings.php.
    – 4uk4
    Commented Apr 16, 2020 at 18:53
  • Reverse Proxy Configuration contains proper values in settings.php. Both the urls are allowed and work properly on the server. machinename url does not resolve from web, but does resolve on server. Thanks for the suggestion. Commented Apr 16, 2020 at 19:35
  • Proper settings would result in a symfony request which includes the hostname the client has requested and not the machine name resolved from your internal DNS. See symfony.com/doc/current/deployment/proxies.html
    – 4uk4
    Commented Apr 16, 2020 at 22:26
  • I think the reverse proxies for Symfony are set in Drupal settings.php using $settings['trusted_host_patterns'] $settings['trusted_host_patterns'] = array( '^mysite\.com$', '^computername\.domain\.com$', '^localhost$', '.*' ); If there is another way to configure Symphony reverse proxy in Drupal, would appreciate guidance. Also getting redirect error like in this issue is related: drupal.org/project/drupal/issues/2753591 Commented Apr 18, 2020 at 15:58
  • 1
    No, trusted host patterns is a security feature preventing the client from providing fake hostnames. The problem you have is that you don't even get the hostname the client is requesting, so you don't have to worry about which hostname you trust until you get the configuration right to receive the client request data correctly in your hosting environment behind a CDN.
    – 4uk4
    Commented Apr 18, 2020 at 16:10

1 Answer 1


Check the "Reverse Proxy Configuration" in settings.php:

 * Reverse Proxy Configuration:
 * Reverse proxy servers are often used to enhance the performance
 * of heavily visited sites and may also provide other site caching,
 * security, or encryption benefits. In an environment where Drupal
 * is behind a reverse proxy, the real IP address of the client should
 * be determined such that the correct client IP address is available
 * to Drupal's logging, statistics, and access management systems. In
 * the most simple scenario, the proxy server will add an
 * X-Forwarded-For header to the request that contains the client IP
 * address. However, HTTP headers are vulnerable to spoofing, where a
 * malicious client could bypass restrictions by setting the
 * X-Forwarded-For header directly. Therefore, Drupal's proxy
 * configuration requires the IP addresses of all remote proxies to be
 * specified in $settings['reverse_proxy_addresses'] to work correctly.
 * Enable this setting to get Drupal to determine the client IP from the
 * X-Forwarded-For header. If you are unsure about this setting, do not have a
 * reverse proxy, or Drupal operates in a shared hosting environment, this
 * setting should remain commented out.
 * In order for this setting to be used you must specify every possible
 * reverse proxy IP address in $settings['reverse_proxy_addresses'].
 * If a complete list of reverse proxies is not available in your
 * environment (for example, if you use a CDN) you may set the
 * $_SERVER['REMOTE_ADDR'] variable directly in settings.php.
 * Be aware, however, that it is likely that this would allow IP
 * address spoofing unless more advanced precautions are taken.
# $settings['reverse_proxy'] = TRUE;

 * Specify every reverse proxy IP address in your environment.
 * This setting is required if $settings['reverse_proxy'] is TRUE.
# $settings['reverse_proxy_addresses'] = ['a.b.c.d', ...];

 * Reverse proxy trusted headers.
 * Sets which headers to trust from your reverse proxy.
 * Common values are:
 * - \Symfony\Component\HttpFoundation\Request::HEADER_X_FORWARDED_ALL
 * - \Symfony\Component\HttpFoundation\Request::HEADER_FORWARDED
 * Note the default value of
 * @code
 * \Symfony\Component\HttpFoundation\Request::HEADER_X_FORWARDED_ALL | \Symfony\Component\HttpFoundation\Request::HEADER_FORWARDED
 * @endcode
 * is not secure by default. The value should be set to only the specific
 * headers the reverse proxy uses. For example:
 * @code
 * \Symfony\Component\HttpFoundation\Request::HEADER_X_FORWARDED_ALL
 * @endcode
 * This would trust the following headers:
 * @see \Symfony\Component\HttpFoundation\Request::HEADER_X_FORWARDED_ALL
 * @see \Symfony\Component\HttpFoundation\Request::HEADER_FORWARDED
 * @see \Symfony\Component\HttpFoundation\Request::setTrustedProxies
# $settings['reverse_proxy_trusted_headers'] = \Symfony\Component\HttpFoundation\Request::HEADER_X_FORWARDED_ALL | \Symfony\Component\HttpFoundation\Request::HEADER_FORWARDED;

There are more infos in the symfony documentation https://symfony.com/doc/current/deployment/proxies.html


For debugging add a line to index.php and check the headers the CDN sending:



 * @file
 * The PHP page that serves all page requests on a Drupal installation.
 * All Drupal code is released under the GNU General Public License.
 * See COPYRIGHT.txt and LICENSE.txt files in the "core" directory.

use Drupal\Core\DrupalKernel;
use Symfony\Component\HttpFoundation\Request;

// remove after debugging    
  • This answer works really well for configuring the reverse proxy, which I had not done. I found the IP address using var_dump($_SERVER); in index.php. Went with $settings['reverse_proxy_trusted_headers'] = \Symfony\Component\HttpFoundation\Request::HEADER_X_FORWARDED_ALL; Removing the server name from my trusted_host_patterns fixed the $base_root issue. THANK YOU! I've struggled with this issue of and on for months. Commented Apr 20, 2020 at 0:00

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.