1 Discovering the Problem: Plugins Cannot Be Updated After Upgrade

Recently, due to security vulnerability fixes, the frequency of WordPress version updates has significantly increased. Since the official release of 7.0, it has been updated to 7.0.3 in less than 3 months. Because the updates were so frequent, I eventually became somewhat “numb” to them. Whenever I saw a new version, I would basically upgrade directly, too lazy to check the changelogs one by one.

However, after upgrading to WordPress 7.0.3 this time, I encountered a problem that had never occurred before—the WordPress at my home suddenly could not normally complete operations that require an internet connection.

Specifically, when WordPress needs to actively access the external network—for example, installing new plugins, updating installed plugins, or fetching official WordPress resources—operations that previously only required clicking a few buttons in the dashboard now frequently result in the following errors:

But strangely, the Chicago VPS node running the same WordPress 7.0.3 was completely normal, without any anomalies. Therefore, the scope of the problem was quickly narrowed down:There should be no issue with the WordPress program itself; what is actually causing the impact is very likely some factors in my home network environment.

Due to the special network environment in China, to allow home devices to ”access the internet normally,” I use a combination of ”iKuai” + ”AC86U”:

Simply put: traffic from devices requiring special network access will first go through iKuai for traffic splitting, and then be forwarded to the AC86U, which completes the subsequent access via a transparent proxy.

This architecture has been running for a long time, and everything including WordPress, Emby, and other home services has been working normally.

So here comes the question: why would a routine WordPress upgrade suddenly cause a long-term, stably running home WordPress node to fail to connect to the internet normally? Could a routine version update actually change certain network access behaviors?

With this question in mind, I began to further investigate the changes behind WordPress 7.0.3.

2 SSRF Protection Mechanism in WordPress 7.0.3

Looking directly at the official 7.0.3 version changelog, I immediately spotted the ”suspect” by intuition: ”A Server-Side Request Forgery (SSRF) vulnerability exists during URL validation, which could allow an attacker to induce WordPress to make requests to local or link-local address ranges":

Although the official description looks quite professional, it actually involves a very basic mechanism of WordPress:The server side actively initiating HTTP requests.

Many functions in the WordPress dashboard are not completed directly by the user's browser, but rather by the server running WordPress actively accessing external resources. For example, functions like plugin installation, plugin updates, theme updates, and version checks all rely on WordPress actively sending requests to external servers:

用户电脑
   |
   | 1. 提交更新操作
   ↓
WordPress 后台程序
   |
   | 2. 服务器主动访问
   ↓
downloads.wordpress.org

And this is precisely the basis for the occurrence of SSRF (Server-Side Request Forgery) vulnerabilities—if an attacker can control the target URL requested by the server, they might induce the server to access some addresses that should not be accessed.

Precisely because of the security risks that server-side requests can bring, WordPress strengthened the security validation of HTTP request targets in version 7.0.3. Simply put, before initiating a request, WordPress no longer just determines whether the target URL is correctly formatted, but further resolves the IP address corresponding to that URL and checks whether the target address falls within a range that should not be accessed by the server.

For example:

127.0.0.0/8       回环地址
10.0.0.0/8        私有网络
172.16.0.0/12     私有网络
192.168.0.0/16    私有网络
169.254.0.0/16    链路本地地址
198.18.0.0/15     网络测试地址

0.0/8 Private network

0.0/12 Private network0.0/16 Private network 0.0/16 Link-local address

0.0/15 Network test address

These addresses do not belong to the normal public network access range, so they are heavily checked by the SSRF protection mechanism: if the IP resolved from the target URL belongs to these special address ranges, WordPress will consider the request to have a potential risk and block further access. This is also the purpose of WordPress 7.0.3 strengthening URL validation: to prevent attackers from using the server's active request capability to access internal resources that should not be exposed.

3 Fake-IP Mechanism in Transparent Proxies

However, the normal operation of the security check relies on a premise:WordPress's judgment on the nature of the target address must be correct.

If this judgment process is affected by other factors, it may lead to normal requests being intercepted by the security mechanism.According to normal logic, official WordPress servers obviously should not belong to any internal network range. So why would the same plugin update request trigger an SSRF risk judgment in my home network environment?Furthermore, under what circumstances would a normal public network access target be resolved into a special address that WordPress considers risky?

Returning to the question left at the end of Chapter 2:

虚拟IP ←→ 目标域名 ←→ 真实IP

Troubleshooting to this point, I thought of a network mechanism that can change the target IP:

客户端
 |
 | DNS查询：www.example.com
 ↓
透明代理设备
 |
 | 生成虚拟IP，并保存映射关系
 ↓
返回虚拟IP
 |
 | 客户端访问虚拟IP
 ↓
透明代理设备根据映射关系识别目标
 |
 ↓
转发至真实服务器

Because in my home network environment, the transparent proxy solution running on the AC86U is precisely using the Fake-IP mode. 198.18.0.0/16 The core idea of Fake-IP is that when the transparent proxy device receives a DNS query request from a client, it does not directly return the real IP address of the target server, but instead returns a virtual IP address generated by the proxy device. At the same time, the proxy device maintains a mapping relationship internally:

Virtual IP ←→ Target Domain ←→ Real IP

用户访问：
www.example.com

DNS解析：
www.example.com → 140.82.x.x

建立连接：
客户端 → 140.82.x.x

If the transparent proxy device only sees the subsequently established IP connection, it does not know what the client originally accessed was www.example.com, or other domain names that also use this IP address. This is because in real-world network environments, it is very common for one IP address to correspond to multiple domain names, especially in CDN environments:

example-a.com
example-b.com
example-c.com

        ↓

    同一个IP地址

example-b.com

*.google.com      → 代理
*.github.com      → 代理
国外网站          → 代理
国内网站          → 直连

Therefore, to achieve this fine-grained traffic splitting based on domain names, the transparent proxy device needs to obtain the target domain name accessed by the client in advance during the DNS query stage.

The Fake-IP mode is designed precisely to solve this problem: by intervening in the DNS query stage, the proxy device can record the target domain name accessed by the client in advance. When the client subsequently accesses the virtual IP, the proxy device identifies the domain name the client actually wants to access based on the saved mapping relationship, and forwards the request to the corresponding real target.

For transparent proxies, the core value of Fake-IP lies in:It advances the target information, which could originally only be identified during the connection stage, to the DNS resolution stage, enabling the proxy device to perform domain-based traffic control more stably.

In addition to the Fake-IP mode, another common method is the Redir-Host mode:

The Redir-Host mode does not return a virtual address, but instead maintains the traditional DNS resolution method: the transparent proxy device forwards the client's DNS request to the upstream DNS server and returns the real IP address resolution result to the client.

For example, in domestic network environments, the upstream DNS is usually the ISP's DNS, or something like Alibaba 223.5.5.5, Tencent 119.29.29.29 public DNS services.

Once the client establishes a connection based on the resolution result, the proxy device then attempts to determine the target domain name using information obtainable during the connection stage, such as the Host field in HTTP requests or the SNI information in HTTPS handshakes, and decides the subsequent handling method accordingly.

This approach is closer to traditional network behavior, and under normal network conditions, Redir-Host itself does not have obvious issues. The client obtains the real DNS resolution result and then establishes a connection, and the proxy device processes the traffic based on the information from the connection stage, which is basically consistent with the normal internet access process.

However, compared to the Fake-IP mode, the limitation of Redir-Host is that it does not change the result of the client's DNS query; it simply returns the real IP address provided by the upstream DNS server directly. This means that in some special network environments, such as those with DNS pollution, DNS hijacking, or scenarios requiring fine-grained traffic splitting based on domain names, the resolution results obtained by the client may already be affected by the network environment.

Since the Redir-Host mode directly returns the DNS query results, it cannot intervene and adjust the target address during the resolution stage like Fake-IP does, which may lead to compatibility issues in subsequent traffic processing.

For example, some overseas services determine the user's region based on network information such as the IP address obtained from the user's DNS resolution and the egress location, and decide whether to provide services or return different content accordingly. If the client directly obtains the real DNS resolution result and the proxy device cannot intervene at the DNS stage, the access experience may not match expectations.

This is also why, in complex network environments, the Fake-IP mode is more likely to achieve stable results compared to Redir-Host.

However, the Fake-IP mechanism also brings a new problem:When a system only sees the result returned by DNS but does not understand the real meaning behind this IP, how does it determine whether this target address is safe?

4 Conflict Between Fake-IP and SSRF Protection

Chapter 3 introduced how Fake-IP works. For transparent proxy devices, the virtual IP returned by Fake-IP is just an internal mapping identifier:

198.18.x.x
        ↓
downloads.wordpress.org

The proxy device knows the real target behind this IP, so it can forward the traffic normally. However, the problem is:Not all systems involved in network requests are aware of the existence of Fake-IP —WordPress is one of them.

In my home network environment, the actual process is as follows:

WordPress
    |
    | 请求访问 downloads.wordpress.org
    ↓
DNS查询
    |
    ↓
AC86U(Fake-IP)
    |
    | 返回虚拟IP
    ↓
198.18.x.x

x.x

198.18.x.x
=
downloads.wordpress.org 的临时映射

18.x.x

So it can continue proxying and forwarding.

downloads.wordpress.org

解析结果：

198.18.x.x

downloads.wordpress.org

x.x

WordPress
认为：
目标地址存在风险
↓
拒绝请求
↓
插件安装/升级失败

As a result, the two systems have completely different understandings, ultimately leading to:WordPress

5 Resolving the WordPress 7.0.3 Update Failure Issue

This is the essence of the problem:

Fake-IP uses IP addresses as domain mapping identifiers, while SSRF protection uses IP addresses to determine network security boundaries. When both mechanisms act on the same request simultaneously, a semantic conflict occurs. 198.18.x.x The previous analysis has shown that the root cause of this issue is not that WordPress cannot access the external network, nor is it an anomaly in AC86U's Fake-IP proxy.

The real problem is that when WordPress judges the security of the target address based on the DNS resolution result, it sees the

virtual address returned by Fake-IP, rather than the real public server address corresponding to it, thus triggering the SSRF risk judgment.

So, how to solve this problem?

// 允许 WordPress HTTP 请求跳过特殊地址范围检查
add_filter( 'http_request_host_is_external', '__return_true' );

The simplest method is to let WordPress skip the security judgment of the HTTP request target address: functions.php // Allow WordPress HTTP requests to skip special address range checks

This code can be added to the Code Snippets plugin, or to the current theme's

file. Once added, WordPress will no longer refuse access when executing external HTTP requests such as plugin installations or upgrades just because the target address belongs to a special IP range.

However, while this method is simple and effective, it has a broad impact. This is because it essentially tells WordPress that HTTP request targets no longer need to go through the default internal address check. If there are features in the WordPress environment that allow users to control request targets, or if the server has the ability to access internal network resources, this approach will reduce the effectiveness of SSRF protection.

add_filter(
    'http_request_host_is_external',
    function( is_external,host, url ) {ip = gethostbyname( host );

        // 允许 Fake-IP 地址池 198.18.0.0/16
        if ( strpos(ip, '198.18.' ) === 0 ) {
            return true;
        }

        return $is_external;

    },
    10,
    3
);

For the false positive scenario caused by Fake-IP in this article, this handling method can quickly restore normal networking functions; however, in production environments with higher security requirements, it is more recommended to only make exceptions for the special address ranges actually in use.198.18.x.x For my home network environment, a more reasonable approach is to only allow the address pool used by Fake-IP, rather than skipping the check entirely. For example:

Of course, modifying the SSRF judgment logic of WordPress is not the only way to solve this problem. For example, you can also start with the network environment, allowing WordPress's DNS requests to bypass Fake-IP resolution and directly obtain the real IP of the target server; or configure a separate proxy egress for WordPress so that it does not go through the current transparent network environment.

These solutions can all theoretically prevent Fake-IP addresses from triggering SSRF checks, but their problem lies in:What is changed is the entire network access path, rather than targetedly resolving WordPress's misjudgment of Fake-IP addresses.

For home data center environments, Fake-IP usually handles more than just the access needs of a single application; it serves as the transparent network proxy infrastructure for the entire home network. Bypassing this architecture solely for WordPress would instead increase additional maintenance costs and potentially lead to inconsistent network behavior.

Therefore, when the network environment is already confirmed to be trusted, making precise adjustments to WordPress's HTTP request judgment is actually the solution with the lowest cost and the smallest scope of impact.

6 Looking at the Complexity of Modern Network Environments Through a WordPress Update Failure

The issue of plugin “Installation failed: Download failed. Invalid URL” caused by this WordPress 7.0.3 update, if looking only at the final solution, seems to be just a matter of bypassing the check by adding a piece of code.

But looking back at the entire troubleshooting process, we can see that this is not a simple software compatibility issue, but rather a type of problem that is becoming increasingly common in modern network environments: the environment that applications rely on to run is no longer a simple, transparent network connection.

In traditional network models, when an application accesses an external service, it can usually be assumed that the address returned by DNS represents the access location of the target service. The application obtains the target address through domain name resolution, then establishes a connection, and judges based on this information whether the target is accessible, trusted, and whether there are security risks.

However, with the development of Internet infrastructure, more and more middle layers responsible for processing and optimizing traffic have appeared in the network request chain. For example, CDNs return different nodes based on user location; load balancers dynamically allocate request targets based on policies; security gateways in corporate networks inspect and process traffic; and virtual networks in cloud environments also redefine the access relationships between services.

These mechanisms themselves exist to solve practical problems, but they also change an important premise in traditional network models: applications usually default to assuming that the network information they obtain can reflect the actual situation of the accessed target.

When a request is processed by multiple middle layers, the information seen by the application may only be the result processed by a certain network component, rather than the complete state of the environment. At this point, when different components understand this information based on their own perspectives, compatibility issues may arise.

The root cause of such problems is usually not a design error in a certain component, but rather differences in the understanding of the same information between different components, or reliance on different assumptions.

For users who build home data centers themselves, this also means a change: in the past, when deploying services, more attention was paid to hardware performance, service configuration, and network connectivity; but as network architectures become increasingly complex, it is also necessary to further understand which middle layers the requests pass through, which components affect network information, and on what information the security mechanisms actually base their judgments.

Many seemingly accidental problems are actually the result of the joint action of multiple components in a complex system. Viewed individually, each component is fulfilling its own responsibility; but when they are combined, interaction effects may occur that the designers did not initially anticipate.

The value of this WordPress update issue lies precisely here: it reminds us that in modern network environments, understanding the relationships between components has become just as important as understanding the individual components themselves.