1. Issue discovered: Plugins cannot be updated after the upgrade.

Recently, due to the fixes for security vulnerabilities, WordPress has been updating at a significantly higher frequency. Since the official release of version 7.0, it has been updated to 7.0.3 in less than three months. Because the updates are so frequent, I've become somewhat desensitized. Whenever a new version is released, I basically upgrade immediately, and I'm too lazy to check the changelogs one by one.

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

Specifically, when WordPress needs to actively access the external network, such as installing new plugins, updating existing plugins, or accessing official WordPress resources, operations that previously only required clicking a few buttons in the backend now frequently result in the following errors:

Strangely, the Chicago VPS node, also running WordPress 7.0.3, functioned perfectly normally without any issues. Therefore, the problem area was quickly narrowed down:The WordPress program itself should be fine; the real issue is likely due to certain factors in my home network environment.

Due to the unique network environment in China, in order to enable my home devices to "connect to the internet normally," I used a combination of "iKuai" and "AC86u":

In simple terms: Device traffic that requires special network access will first be routed through iKuai and then forwarded to AC86U, where AC86U will complete the subsequent access through a transparent proxy.

This architecture has been running for a long time, and WordPress, Emby, and other home services have all been working perfectly.

So here's the question: Why would a routine WordPress upgrade cause a long-running, stable home WordPress node to suddenly lose internet connectivity? Could a simple version update really alter certain network access behaviors?

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

2. SSRF Protection Mechanism in WordPress 7.0.3

A quick glance at the official 7.0.3 changelog reveals the "suspect": a Server-Side Request Forgery (SSRF) vulnerability exists in the URL verification process, which could allow attackers to trick WordPress into making requests to local or link-local address ranges.

Although the official description sounds technical, it actually involves a very basic mechanism of WordPress:The server initiates an HTTP request.

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

User's computer | | 1. Submit an update ↓ WordPress admin panel | | 2. Server actively accesses ↓ downloads.wordpress.org

This is the basis of the SSRF (Server-Side Request Forgery) vulnerability—if an attacker can control the target URL of a server request, they may be able to trick the server into accessing addresses that should not be accessed.

Because of the potential security risks associated with server-side requests, WordPress strengthened the security verification of HTTP request targets in version 7.0.3. Simply put, before initiating a request, WordPress no longer simply checks if the target URL is formatted correctly; instead, it further parses the IP address corresponding to the URL and checks whether the target address belongs to a range that should not be accessed by the server.

For example:

127.0.0.0/8 Loopback address 10.0.0.0/8 Private network 172.16.0.0/12 Private network 192.168.0.0/16 Private network 169.254.0.0/16 Link-local address 198.18.0.0/15 Network test address

These addresses are not within the normal public network access range, and therefore will be subject to special checks by the SSRF protection mechanism: if the IP address resolved to the target URL belongs to these special address ranges, WordPress will consider the request potentially risky and block further access. This is also the purpose of WordPress 7.0.3's enhanced URL verification: to prevent attackers from using the server's ability to actively request access to internal resources that should not be exposed.

However, the normal operation of security checks depends on one prerequisite:WordPress must correctly determine the nature of the target address. If this judgment process is affected by other factors, it may cause normal requests to be blocked by security mechanisms.

Logically, the official WordPress server shouldn't belong to any internal network. So why did the same plugin update request trigger an SSRF risk assessment in my home network environment?

Furthermore, under what circumstances would a normal public network access target be resolved to a special address that WordPress considers risky?

3. Fake-IP Mechanism in Transparent Proxy

Returning to the question left at the end of Chapter Two:Under what circumstances would a normal public network access target be resolved to a special address that WordPress considers risky?

After investigating this far, I thought of a network mechanism that could change the target IP address:Fake-IPBecause in my home network environment, the transparent proxy solution running on the AC86U uses the Fake-IP mode.

The core idea of Fake-IP is that when a transparent proxy device receives a DNS query request from a client, it does not directly return the target server's real IP address, but instead returns a virtual IP address generated by the proxy device. Simultaneously, the proxy device internally maintains a mapping relationship:

Virtual IP ←→ Target Domain ←→ Real IP

This virtual IP is not the actual address of the target server, but rather a temporary identifier generated by the proxy system to identify the target domain name. In short, the workflow of a fake IP is as follows:

Client | DNS lookup: www.example.com ↓ Transparent proxy device | Generates a virtual IP and saves the mapping relationship ↓ Returns the virtual IP | Client accesses the virtual IP ↓ Transparent proxy device identifies the target based on the mapping relationship | ↓ Forwards to the real server

It's important to note that the virtual IP address returned by Fake-IP is not a randomly generated public IP address, but typically comes from a specially reserved address pool. For example, transparent proxy solutions like Clash usually use this by default. 198.18.0.0/16 This is a pool of fake IP addresses. The address falls within the network test address range defined in RFC 2544 and is not a regular public IP address.

So why does a transparent proxy need to use this method instead of directly returning the real IP address? The reason is that for domain-based proxy traffic routing, simply knowing the IP address of the final connection is insufficient. For example:

User visits: www.example.com DNS resolution: www.example.com → 140.82.xx Connection established: Client → 140.82.xx

If the transparent proxy device only sees the subsequently established IP connections, it doesn't know that the client initially accessed... www.example.comOr other domains using the same IP address? This is because in the real-world network environment, it is very common for one IP address to correspond to multiple domains, especially in a CDN environment:

example-a.com example-b.com example-c.com ↓ Same IP address

Therefore, relying solely on IP addresses cannot accurately determine the domain name a client is currently accessing. However, many proxy rules are precisely based on domain names, for example:

*.google.com → Proxy *.github.com → Proxy for foreign websites → Proxy for domestic websites → Direct connection

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

The Fake-IP mode is designed to solve this problem: by intervening during the DNS lookup phase, the proxy device can pre-record the target domain name accessed by the client. 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 and forwards the request to the corresponding real target.

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

Besides the Fake-IP mode, another common method is the Redir-Host mode:

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

For example, in the domestic network environment, the upstream DNS is usually the ISP's DNS, or similar to Alibaba's DNS. 223.5.5.5Tencent 119.29.29.29 Such public DNS services.

After the client establishes a connection based on the resolution result, the proxy device then attempts to determine the target domain name using information that can be obtained during the connection phase, such as the Host field in the HTTP request or the SNI information in the HTTPS handshake, and decides on the subsequent processing method accordingly.

This approach is closer to traditional network behavior, and under normal network conditions, Redir-Host itself does not present any significant problems. The client obtains the actual DNS resolution result, then establishes a connection, and the proxy device processes the traffic based on the information from the connection process, which is essentially the same as the normal internet access process.

However, compared to the Fake-IP mode, Redir-Host has a limitation: it does not change the client's DNS query results; it simply returns the real IP address provided by the upstream DNS server. This means that in certain 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 Redir-Host mode directly returns DNS query results, it cannot intervene and adjust the target address during the resolution stage like Fake-IP, which may lead to compatibility issues in subsequent traffic processing.

For example, some overseas services determine a user's region based on network information such as the IP address and exit point obtained from DNS resolution, and decide whether to provide service or return different content accordingly. If the client directly obtains the actual DNS resolution result, and the proxy device cannot intervene at the DNS stage, the access experience may be inconsistent with expectations.

This is 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 results returned by DNS but doesn't understand the true meaning behind the IP address, how can it determine whether the target address is safe?

4. Conflicts arising from Fake-IP and SSRF protection

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

198.18.xx ↓ downloads.wordpress.org

The proxy device knows the real target behind this IP, so it can forward the message normally. However, the problem is:Not all systems participating in network requests are aware of the existence of fake IPs. WordPress is one of them.

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

WordPress | | Requesting access to downloads.wordpress.org ↓ DNS lookup | ↓ AC86U (Fake-IP) | | Returning virtual IP ↓ 198.18.xx

For AC86U:

198.18.xx = Temporary mapping for downloads.wordpress.org

Therefore, it can continue to act as a proxy for forwarding.

However, for WordPress:

The URL parsing result for downloads.wordpress.org is: 198.18.xx

It doesn't know that this IP address is a virtual address in the fake IP address pool. It can only determine, according to its own security rules, whether this target IP address belongs to a special address that should not be accessed.

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

WordPress considers the following to be true: Target address is risky ↓ Request rejected ↓ Plugin installation/upgrade failed

This is the essence of the problem:Fake-IP uses IP addresses as domain name mapping identifiers, while SSRF protection uses IP addresses to determine network security boundaries. When both mechanisms are applied to the same request, a semantic conflict arises.

5. Resolving WordPress 7.0.3 Update Failure Issues

The preceding analysis has shown that the root cause of this problem is neither WordPress's inability to access the external network, nor the AC86U's Fake-IP proxy anomaly.

The real problem is that when WordPress determines the security of a target address based on DNS resolution results, it is seeing a fake IP returned. 198.18.x.x The virtual address, rather than the actual public server address behind it, triggered an SSRF risk assessment.

So, how do we solve this problem?

Since Fake-IP is the foundation of my home network infrastructure, directly modifying the transparent proxy solution is impractical. Therefore, the only solution is to return to WordPress itself and make it adaptable to the current network environment.

The simplest method is to make WordPress skip the security check on the target URL of the HTTP request:

// Allow WordPress HTTP requests to skip special address range checks add_filter( 'http_request_host_is_external', '__return_true' );

This code can be added to the Code Snippets plugin, or to the current theme. functions.php In the file. After adding this, WordPress will no longer reject external HTTP requests such as plugin installations and upgrades because the target address belongs to a specific IP range.

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

For scenarios like the one described in this article where misjudgment is caused by Fake-IP, this approach can quickly restore normal network connectivity. However, in production environments with high security requirements, it is recommended to make exceptions only for specific address ranges that are actually in use.

For my home network environment, a more reasonable approach would be to only allow access to the address pool used by fake IPs, rather than completely skipping the checks. For example:

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
);

After this processing:198.18.x.x Fake IP addresses will be allowed access; other special addresses will still maintain WordPress's original SSRF check logic, which is more in line with actual security needs.

Of course, modifying WordPress's SSRF detection logic isn't the only way to solve this problem. For example, you can work on the network environment by allowing WordPress's DNS requests to bypass Fake-IP resolution and directly obtain the target server's real IP address; or you can configure a separate proxy exit for WordPress so that it doesn't go through the current transparent proxy environment.

These solutions can theoretically avoid SSRF checks triggered by fake IP addresses, but their problem is:The change is to the entire network access path, rather than specifically addressing WordPress's misjudgment of fake IP addresses.

In a home data center environment, Fake-IP typically handles more than just the access needs of a single application; it serves as a transparent proxy infrastructure for the entire home network. Bypassing this architecture specifically for WordPress would actually increase maintenance costs and potentially lead to inconsistent network behavior.

Therefore, given that the network environment has been confirmed to be trustworthy, making precise adjustments to the HTTP request handling for WordPress is actually the lowest-cost and least impactful solution.

6. The Complexity of the Modern Web Environment as Seen Through a WordPress Update Failure

The WordPress 7.0.3 update caused a plugin "Installation failed: Download failed. Invalid URL" issue. If you only look at the final solution, it seems to be a simple matter of bypassing the check by adding a piece of code.

However, a review of the entire investigation process reveals that this is not a simple software compatibility issue, but rather a problem that is becoming increasingly common in modern network environments: the environment on which applications rely for runtime is no longer a simple, transparent network connection.

In traditional network models, when an application accesses an external service, the address returned by DNS is typically considered to represent the location of the target service. The application obtains the target address through domain name resolution, then establishes a connection and uses this information to determine whether the target is accessible, trustworthy, and whether there are any security risks.

However, with the development of internet infrastructure, more and more middleware layers have emerged in the network request chain, responsible for processing and optimizing traffic. For example, CDNs return different nodes based on the user's location; load balancers dynamically allocate request targets according to policies; security gateways in enterprise networks inspect and process traffic; and virtual networks in cloud environments redefine the access relationships between services.

These mechanisms exist to solve practical problems, but they also change an important premise in the traditional network model: applications usually assume that the network information they obtain reflects the actual situation of the target being accessed.

When a request passes through multiple intermediate layers, the information seen by the application may only be the result processed by a single network component, rather than the complete state of the environment. In this case, compatibility issues may arise when different components interpret this information from their own perspectives.

The root cause of these problems is usually not a design flaw in a particular component, but rather a difference in how different components understand the same information or rely on different underlying assumptions.

For users who build their own home data centers, 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 architecture becomes more complex, it is also necessary to further understand which intermediate layers the request passes through, which components affect network information, and what information the security mechanism bases its judgment on.

Many seemingly accidental problems are actually the result of the combined effects of multiple components in a complex system. Individually, each component fulfills its own responsibility; but when they are combined, interactive effects that the designer did not initially anticipate may occur.

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