WireGuard Direct Connection in China With Overseas Tunneling: Pitfalls and a Verified Solution

⚠️ This article records an older WireGuard traffic splitting solution (since upgraded)

In current practice, this solution has the following issues:

• Cannot handle complex domain-based traffic splitting
• Relies on manual AllowedIPs configuration
• Not suitable for multi-node/VPS hybrid architectures

👉 Recommended upgrade solution:
🚀 WireGuard + Clash Verge Rev for domestic direct connection / foreign traffic splitting (Vultr & ZgoCloud practical evolution edition)

As a user who frequently needs to access overseas websites (ChatGPT, YouTube, Google Translate, etc.), I have always wanted to implement WireGuard’s “direct connection for domestic websites, tunnel for foreign websites” feature—ensuring native speeds for domestic web pages while stably accessing overseas services, and avoiding the unnecessary traffic consumption caused by a global proxy. During the process, I fell into a very typical routing configuration pitfall. After some troubleshooting, I achieved a perfect resolution and organized it into this blog post to help friends with the same needs avoid the same mistakes.

1. Background and Requirements
I initially configured the WireGuard client but encountered a strange issue:

• Google Translate (https://translate.google.com/) opened normally
• ChatGPT (https://chatgpt.com/), YouTube (https://www.youtube.com/), and V2EX (https://v2ex.com/) consistently failed to open, showing an inaccessible prompt. See Figure 1
  

• I suspected insufficient server bandwidth, but testing the base bandwidth showed it was completely sufficient, ruling out a bandwidth issue.
  Core requirement: Retain the traffic splitting logic of direct connection for domestic traffic and tunneling for foreign traffic, resolve the issue of certain overseas websites being inaccessible, and do so without increasing server configuration.

2. Initial Configuration (Pitfall Version)
The initial WireGuard client configuration was as follows, and the problem lay in the AllowedIPs line. For reference: WireGuard VPN Configuration Optimization: Direct Connection for Domestic Websites, VPN for Foreign Traffic (Verified Effective), which did not thoroughly solve the problem previously. See Figure 2

[Interface]
PrivateKey = MNcoOjHNvao4gH1...
Address = 10.66.66.2/32, fd42:42:42::2/128
DNS = 223.5.5.5, 223.6.6.6

[Peer]
PublicKey = XZ2LNJxO7RqjGKHyubFw35eR7AkRa1iHqltQJYdsY3g=
PresharedKey = Fz04FNeapuPYQ+QAH+...
AllowedIPs = 0.0.0.0/1, 128.0.0.0/2, ::/1, 8000::/1
Endpoint = 139.180.154.26:2096
PersistentKeepalive = 25

[Interface]
PrivateKey = MNcoOjHNvao4gH1...
Address = 10.66.66.2/32, fd42:42:42::2/128
DNS = 223.5.5.5, 223.6.6.6

[Peer]
PublicKey = XZ2LNJxO7RqjGKHyubFw35eR7AkRa1iHqltQJYdsY3g=
PresharedKey = Fz04FNeapuPYQ+QAH+...
AllowedIPs = 0.0.0.0/1, 128.0.0.0/2, ::/1, 8000::/1
Endpoint = 139.180.154.26:2096
PersistentKeepalive = 25

3. Troubleshooting: Incomplete AllowedIPs Subnet Coverage
At first, I mistakenly thought the bandwidth was insufficient. Later troubleshooting revealed that the root cause was the incomplete IPv4 subnet configuration in AllowedIPs, which caused a large number of overseas IPs to be excluded from the tunnel routing, making them inaccessible.

1. First, understand the coverage of 0.0.0.0/1, 128.0.0.0/2

• 0.0.0.0/1: Covers the first half of IPv4 addresses, i.e., 0.0.0.0 ~ 127.255.255.255
• 128.0.0.0/2: Only covers the first quarter of the second half of IPv4, i.e., 128.0.0.0 ~ 191.255.255.255
  Key flaw: Combined, these two subnets miss the large block of IP addresses from 192.0.0.0 ~ 255.255.255.255. Servers for overseas tech giants like ChatGPT and YouTube happen to fall exactly within these omitted subnets like 192.x, 203.x, and 204.x, so they cannot be accessed through the tunnel and naturally fail to open.

1. Additional note: The IPv6 configuration is correct
   The IPv6 portion ::/1, 8000::/1 in the initial configuration is completely correct:

• ::/1: Covers all addresses in the first half of IPv6
• 8000::/1: Covers all addresses in the second half of IPv6
  Combined, these two fully cover all IPv6 addresses, ensuring that all overseas IPv6 traffic goes through the tunnel. This is why no IPv6-related access issues occurred.

4. Perfect Solution: Complete Traffic Splitting Configuration (Domestic Direct + Foreign Tunnel)
The core of solving the problem is replacing the IPv4 portion of AllowedIPs with a complete summary of overseas IPv4 subnets to cover all overseas IPs, while retaining the logic for direct domestic IP connections.
The final working configuration (ready to copy and use) is shown in Figure 3

[Interface]
PrivateKey = MNcoOjHNvao4gH1...
Address = 10.66.66.2/32, fd42:42:42::2/128
DNS = 223.5.5.5, 223.6.6.6

[Peer]
PublicKey = XZ2LNJxO7RqjGKHyubFw35eR7AkRa1iHqltQJYdsY3g=
PresharedKey = Fz04FNeapuPYQ+QAH+...
# Core: Complete overseas IPv4 + full coverage IPv6, implementing domestic direct connection and foreign tunnel
AllowedIPs = 1.0.0.0/8, 2.0.0.0/7, 4.0.0.0/6, 8.0.0.0/5, 16.0.0.0/4, 32.0.0.0/3, 64.0.0.0/2, 128.0.0.0/1, ::/1, 8000::/1
Endpoint = 139.180.154.26:2096
PersistentKeepalive = 25

[Interface]
PrivateKey = MNcoOjHNvao4gH1...
Address = 10.66.66.2/32, fd42:42:42::2/128
DNS = 223.5.5.5, 223.6.6.6

[Peer]
PublicKey = XZ2LNJxO7RqjGKHyubFw35eR7AkRa1iHqltQJYdsY3g=
PresharedKey = Fz04FNeapuPYQ+QAH+...
# Core: Complete overseas IPv4 + full coverage IPv6, implementing domestic direct connection and foreign tunnel
AllowedIPs = 1.0.0.0/8, 2.0.0.0/7, 4.0.0.0/6, 8.0.0.0/5, 16.0.0.0/4, 32.0.0.0/3, 64.0.0.0/2, 128.0.0.0/1, ::/1, 8000::/1
Endpoint = 139.180.154.26:2096
PersistentKeepalive = 25

Configuration notes (safe to use, no extra steps required)

1. IPv4 portion: The sequence of subnets from 1.0.0.0/8 to 128.0.0.0/1 completely covers all overseas IPv4 addresses while avoiding domestic IPv4 subnets, achieving direct connection for domestic traffic and tunneling for foreign traffic.
2. IPv6 portion: Retains the correct ::/1, 8000::/1, fully covering all IPv6 addresses to ensure overseas IPv6 traffic properly goes through the tunnel.
3. Other parameters: No need to modify PrivateKey, Endpoint, etc.; simply replace AllowedIPs.
   Operation steps (done in 3 steps)
4. Open the WireGuard client and edit the current configuration file;
5. Delete the original AllowedIPs line, and copy the complete AllowedIPs above to replace it;
6. Save the configuration, disconnect the WireGuard connection, reactivate it, and test access.

5. Test Results (Verified)
After modifying the configuration and reconnecting WireGuard, the test results were as follows:

• Domestic websites: Baidu, Taobao, Bilibili, WeChat, etc., all connect directly with speeds consistent with having no proxy enabled;
• Overseas websites: ChatGPT, YouTube, Google Translate, V2EX (Note: I originally thought this was a domestic website, but surprisingly its server is located overseas), etc., all open normally and run smoothly without lag. See Figure 4

• No need to increase server bandwidth; a basic 1C1G server is sufficient for daily use (perfectly adequate for browsing YouTube and using ChatGPT).

6. Pitfall Avoidance Summary (Key Takeaways)

1. Do not use 0.0.0.0/1, 128.0.0.0/2 as IPv4 traffic splitting rules; this will miss a large number of overseas IPs, causing some overseas websites to be inaccessible;
2. For IPv6 traffic splitting, ::/1, 8000::/1 is sufficient for full coverage and requires no modification;
3. If overseas websites fail to open, prioritize checking AllowedIPs subnet coverage rather than server bandwidth (in most cases, it is unrelated to bandwidth);
4. To achieve direct domestic connection + foreign tunneling, directly use the complete AllowedIPs provided in this article; no extra configuration is needed, just a one-click fix.
   If individual overseas websites remain inaccessible after the modification, it is highly likely that the website’s IP is not included in the summary subnets. You can leave a comment to report it, and simply add a precise routing rule. I hope this blog post helps friends who are also tinkering with WireGuard traffic splitting avoid pitfalls and detours!

The standalone WireGuard traffic splitting method has gradually been replaced by the Clash rule system.

It is recommended to prioritize the new architecture solution (see the link above).