1 Introduction
When we use WordPress to build our own personal blog, a common problem we often encounter is the need to use multiple ways to access WordPress. For example, on the intranet, I want to use the internal IP address 192.168.x.x to access it; on the extranet, I want to use the domain name bbs1.example.com to access it, or I also want to use bbs2.example.com to access it. This kind of demand is actually very normal and common, but it cannot be achieved in default WordPress, because by default WordPress will bind the access address used during initialization (which may be an IP or a domain name).
Actually, if the SSL decryption step is not done by WordPress itself (the common practice now is that if there is a reverse proxy, SSL decryption is performed on the reverse proxy), then the action of WordPress locking down an access address does not make much sense from a security perspective, because the access domains of requests that can reach WordPress through the reverse proxy must be correct.
To enable WordPress to support multi-domain access, generally speaking, there are 3 implementation methods.
2 Method 1: Modify wp-config.php
The access domain bound when initializing WordPress is stored in the database, specifically in the table wp_options within the corresponding WordPress database:
Therefore, many issues where WordPress becomes inaccessible due to failed attempts to change the WordPress access domain, IP, or HTTP to HTTPS can be fixed by directly modifying the addresses in the database. Among them, home and siteurl correspond to the WordPress Address and Site Address respectively, as shown in the figure below:
Note: If you want to use the method of directly modifying the database, you can use the command line or various database clients (DBeaver, phpMyAdmin, etc.) to modify it directly. I won't go into detail here, as there are many articles on the internet introducing this, and it is not the focus of what I want to talk about today.
The method of modifying wp-config.php that we will discuss in this section utilizes the principle in WordPress that for the same setting data, constants have a higher priority than variables defined in the database. WordPress has two constants, WP_HOME and WP_SITEURL, which correspond to home and siteurl in the database respectively. Therefore, as long as these 2 constants are set in wp-config.php, they will take effect with priority over the settings in the database. There are the following 2 modification approaches.
Fully open, without any restrictions
In the wp-config.php file,define('WP_DEBUG', false);add the following code after it:
$scheme = 'http';
if (
isset($_SERVER['HTTP_X_FORWARDED_PROTO']) &&
$_SERVER['HTTP_X_FORWARDED_PROTO'] === 'https'
) {
$scheme = 'https';
}
define('WP_SITEURL', $scheme . '://' . $_SERVER['HTTP_HOST']);
define('WP_HOME', $scheme . '://' . $_SERVER['HTTP_HOST']);
The function implemented by this code is to dynamically set the WordPress site address based on the real access protocol (HTTP/HTTPS) passed by the reverse proxy and the current Host, ensuring that the correct URL is generated in a Cloudflare Tunnel or regular reverse proxy environment.
Of course, the prerequisite for using this method is that all requests reaching WordPress are normal requests, so this method can only be used in conjunction with a reverse proxy, or by filtering illegal domain requests reaching WordPress through security measures.
Directly limit the domains that can access WordPress
In the wp-config.php file,define('WP_DEBUG', false);add the following code after it:
$host = $_SERVER['HTTP_HOST'];
$allowed_hosts = [
'bbs1.example.com',
'bbs2.example.com',
'bbs3.example.com',
];
if (!in_array($host, $allowed_hosts)) {
$host = 'bbs1.example.com';
}
$scheme = (
isset($_SERVER['HTTP_X_FORWARDED_PROTO']) &&
$_SERVER['HTTP_X_FORWARDED_PROTO'] === 'https'
) ? 'https' : 'http';
define('WP_SITEURL', $scheme . '://' . $host);
define('WP_HOME', $scheme . '://' . $host);
In addition to dynamically setting the WordPress site address based on the real access protocol (HTTP/HTTPS) and the current Host, the function implemented by this code also limits acceptable access entry points through a Host whitelist (such as bbs1.example.com, bbs2.example.com, and bbs3.example.com in the code above) to prevent illegal Host Headers from causing WordPress to generate incorrect URLs (if it is an illegal Host Header, it forces access to bbs1.example.com). This is suitable for scenarios such as reverse proxies, multiple entry points, and direct deployment.
However, it should be noted that the above 2 methods are ineffective for static resources in WordPress, such as attachments and images uploaded to WP. If you want to modify the address of such static resources, you also need to insert the following code:
define( 'WP_CONTENT_URL', '//' . $_SERVER['HTTP_HOST'] . '/wp-content');
Note: Using the method of modifying wp-config.php will cause the siteurl and home in the admin settings interface to turn grey and become unmodifiable:
However, it does not affect normal use; it just might look a bit annoying.
3 Method 2: Modify the current theme's function.php
Method 2 is actually the same as Method 1, both using the approach of setting the two constants WP_HOME and WP_SITEURL, except that Method 1 is set in wp-config.php, while Method 2 is set in the current theme's function.php. The settings are exactly the same, so I won't repeat them here.
4 Method 3: Plugins
There should be quite a few plugins that implement multi-domain access; I previously used Multiple Domain:
It is very simple to use, just directly add the domains used for access, as shown in the figure below:
This plugin is actually very good, but it hasn't been updated for a long time. As someone with OCD, I found it very annoying, so I later switched to the method of modifying wp-config.php.
Note: Using the plugin method will not cause the siteurl and home in the admin settings interface to turn grey.
5 Summary
Different methods do not have absolute pros and cons; the key still depends on your actual needs.
If you are just migrating the website as a whole to a new domain without needing to retain access via the old domain, then directly modifying the site address in the database is usually the simplest and most direct solution. Once configured, WordPress will run normally with the new domain, and almost no additional maintenance will be required afterwards.
If you need to support multiple access entry points at the same time, such as multiple domains, intranet IPs, reverse proxies, Cloudflare Tunnel, Tailscale, etc., then using a plugin, or in wp-config.php、functions.php dynamically setting WP_HOME、WP_SITEURL will be more flexible. This method can automatically generate the corresponding site address based on the access entry point, making it more suitable for some special deployment environments.
It should be noted that,wp-config.php 和 functions.php settings have a higher priority than the database, so they can not only serve as a daily configuration solution but also as an ”emergency measure.” For example, when the site address in the database is misconfigured, or a plugin causes the admin dashboard to be inaccessible, temporarily overriding them in the code WP_HOME 和 WP_SITEURLcan often quickly restore website access, allowing you to log into the dashboard to continue troubleshooting other issues.
It needs to be emphasized again:
If multi-domain access is achieved by setting the two constants WP_HOME and WP_SITEURL, it is recommended not to directly trust $_SERVER['HTTP_HOST'], but instead restrict it in combination with a Host whitelist, and dynamically determine HTTP/HTTPS based on the real access protocol passed by the reverse proxy (such as X-Forwarded-Proto) to dynamically determine HTTP/HTTPS.
This not only balances the flexibility of multi-entry access but also prevents invalid Host Headers from causing WordPress to generate incorrect site URLs, making it more secure and reliable in deployment scenarios such as VPS direct connection, reverse proxy, and Cloudflare Tunnel.