Skillfully Using Hong Kong as a Transit Point to Build a Smooth and Stable Three-Layer Tunnel Between China and the US

In the previous article, “Building a Three-Layer Tunnel with Full US IP and No Manual Proxy Settings,” we addressed many network issues encountered when accessing global services through the architecture of Domestic Server -> US Server. However, a new performance bottleneck has gradually emerged: the public connection between the domestic server and the US server experiences high latency and severe packet loss during peak hours.

This results in issues like SSH operation lag, online meeting disconnections, and API request timeouts, even when using a tunnel. The root cause lies in the international internet link between China and the US, which is like a highway during holidays—congestion is the norm.

Faced with this problem, a counterintuitive solution emerges: If the direct route is blocked, would taking a detour be faster?

Core Insight: Why Adding a Hop Can Be Faster?

The answer is yes, provided the detour is smart. Our chosen detour is Hong Kong.

This choice is based on a key insight: The overall performance of a link depends on its weakest segment. The bottleneck of the Domestic -> US link is precisely the public segment across the Pacific Ocean.

By adding Hong Kong as a transit point, we split an unstable long-distance link into two high-quality links:

1. Domestic -> Hong Kong: The physical distance is short, the network infrastructure is good, and many cloud service providers offer low-latency, high-stability dedicated connections.
2. Hong Kong -> US: As a top network hub in Asia, Hong Kong has ample international bandwidth and high-quality submarine cables to the US.

Ultimately, the Domestic -> Hong Kong -> US “zigzag” route, although adding a node, allows each segment to travel on a VIP lane, with overall speed and stability far exceeding the congested “straight line” path. We trade a negligible forwarding delay for a significant improvement in stability and throughput.

Skillfully Using Hong Kong as a Transit Point

We will build the following data link.

Your Device (WireGuard) → Domestic Server (Xray) → Hong Kong Server (Xray) → US Server (WireGuard) → Internet

You might ask: Why not connect directly from my device to the Hong Kong server and add a domestic server as a springboard?

The answer lies in the network quality of the “first mile.” Our personal home broadband or mobile network cannot guarantee stability when accessing overseas servers (including Hong Kong), especially during peak network periods. In contrast, the data centers of domestic cloud service providers (such as Alibaba Cloud, Tencent Cloud, Huawei Cloud, etc.), especially mainstream nodes (like Beijing, Shanghai, Guangzhou) to Hong Kong, are usually specially optimized, and some qualified companies can even rent dedicated connections. This ensures the stability and low latency of the route from the domestic server to the Hong Kong server. Therefore, by using the domestic server as the tunnel’s entry point, we can effectively avoid fluctuations in the personal network environment and promptly send our data traffic onto the most reliable “highway.”

Data Flow Analysis:

1. Device to Domestic Server: Your computer or phone, as a WireGuard client, sends all network data (UDP packets) to a specific port on the domestic server.
2. Domestic Server to Hong Kong Server: The Xray service on the domestic server receives UDP packets, disguises and encapsulates them in a stable TCP connection using the VLESS protocol, and sends them to Hong Kong.
3. Hong Kong Server to US Server: The Hong Kong server is the key transit point. It receives the VLESS data stream from the domestic server, unpacks the original WireGuard UDP packets, and directly forwards these UDP packets to the WireGuard port on the US server.
4. US Server to Internet: The US server is the tunnel’s endpoint, running only the WireGuard service. It receives UDP packets from Hong Kong, processes them, and sends your traffic out with a US IP, enabling access to the global internet.

Preparation

1. Three Servers:
   • Domestic server (Beijing/Shanghai/Guangzhou, etc., using aliyun-bj as an example)
   • Hong Kong server (using aliyun-hk as an example)
   • US server (using us-west as an example)
2. Software:
   • Xray needs to be installed on the domestic and Hong Kong servers.
   • Only WireGuard needs to be installed on the US server.
3. UUID: We need to generate an ID for the Domestic -> Hong Kong VLESS connection. Please generate and record it in advance:

   1 2 3 4

   # 用于国内 -> 香港 export UUID_BJ_HK=$(uuidgen) echo "北京 -> 香港 的 VLESS UUID: ${UUID_BJ_HK}"

Firewall Configuration

Before configuring the services, ensure that you have allowed the necessary ports for each server in the service provider’s console (such as Alibaba Cloud/Tencent Cloud/AWS security group) or internally on the server (such as ufw, firewalld). This is a crucial step to ensure tunnel connectivity.

• US Server (us-west):

  • Inbound Rule: Allow UDP traffic from the Hong Kong server IP to enter port 42371.
  • Note: This is the port where the WireGuard service listens. For security, it is recommended to allow access only from the Hong Kong server’s IP.

• Hong Kong Server (aliyun-hk):

  • Inbound Rule: Allow TCP traffic from the domestic server IP to enter port 8445.
  • Note: This is the port where the VLESS service listens, used to receive data from the domestic server.

• Domestic Server (aliyun-bj):

  • Inbound Rule: Allow UDP traffic from your local network to enter port 42371.
  • Note: This is the main entry point of the tunnel, where the WireGuard client will connect. If your local IP is not fixed, you can set it to 0.0.0.0/0 (any source), but this will slightly reduce security.

Step-by-Step Configuration Practice

Step 1: Configure the US Endpoint Server (us-west)

The US server is now purely a WireGuard endpoint, making the configuration extremely simple.

1.1 Install Software and Enable BBR

BBR is a TCP congestion control algorithm developed by Google that can significantly improve the server’s TCP performance.

1
2
3
4
5
6
7
8
9
10
11
12
13

# 适用于 Debian/Ubuntu
sudo apt update
sudo apt install -y wireguard

# 开启 BBR
sudo tee -a /etc/sysctl.conf > /dev/null << EOF
net.core.default_qdisc=fq
net.ipv4.tcp_congestion_control=bbr
EOF
sudo sysctl -p

# 验证 BBR 是否已开启 (输出应包含 bbr)
sysctl net.ipv4.tcp_congestion_control

1.2 Configure WireGuard (wg1)

First, generate the key pair for the WireGuard interface wg1.

1

sudo wg genkey | sudo tee /etc/wireguard/wg1_private.key | sudo wg pubkey | sudo tee /etc/wireguard/wg1_public.key

Then, create the configuration file /etc/wireguard/wg1.conf.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

# 获取你的私钥
PRIVATE_KEY=$(sudo cat /etc/wireguard/wg1_private.key)

# 使用 tee 命令写入配置
sudo tee /etc/wireguard/wg1.conf > /dev/null << EOF
[Interface]
Address = 10.10.20.1/24
ListenPort = 42371
PrivateKey = ${PRIVATE_KEY}
MTU = 1280
# PostUp/Down 脚本用于在 wg 启动/关闭时自动配置 NAT 转发规则。
# 1. 允许来自客户端 (%i) 的流量被转发。
# 2. 允许已建立的连接的返回流量通过。
# 3. 对所有从公网网卡 (eth0) 出去的流量进行源地址伪装 (MASQUERADE)。
PostUp = iptables -A FORWARD -i %i -j ACCEPT; iptables -A FORWARD -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT; iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
PostDown = iptables -D FORWARD -i %i -j ACCEPT; iptables -D FORWARD -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT; iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE
EOF

Note: In PostUp/PostDown, eth0 is the public network card name of your server. Please modify it according to the results displayed by ip addr.

1.3 Start the Service

1
2
3
4
5
6
7
8
9

# 开启内核 IP 转发
sudo sed -i '/net.ipv4.ip_forward=1/s/^#//' /etc/sysctl.conf
sudo sysctl -p

# 启动并设置开机自启
sudo systemctl enable --now wg-quick@wg1

# 检查服务状态
sudo systemctl status wg-quick@wg1

Step 2: Configure the Hong Kong Transit Server (aliyun-hk)

The Hong Kong server acts as a “middleman,” responsible for unpacking and forwarding traffic.

2.1 Install Software and Enable BBR

As a TCP tunnel transit point, enabling BBR on the Hong Kong server is crucial for optimizing the VLESS connection from domestic to Hong Kong.

1
2
3
4
5
6
7
8
9
10
11
12
13

# 适用于 Debian/Ubuntu
sudo apt update
sudo apt install -y xray

# 开启 BBR
sudo tee -a /etc/sysctl.conf > /dev/null << EOF
net.core.default_qdisc=fq
net.ipv4.tcp_congestion_control=bbr
EOF
sudo sysctl -p

# 验证 BBR 是否已开启 (输出应包含 bbr)
sysctl net.ipv4.tcp_congestion_control

2.2 Configure Xray

One VLESS entry (receiving domestic data) and one Freedom exit (directly forwarding UDP to the US).

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30

# 请确保已在准备工作中生成了 UUID_BJ_HK
# echo "北京 -> 香港 的 VLESS UUID: ${UUID_BJ_HK}"

# 写入 Xray 配置
sudo tee /usr/local/etc/xray/config.json > /dev/null << EOF
{
  "log": { "loglevel": "warning" },
  "inbounds": [
    {
      "port": 8445,
      "protocol": "vless",
      "settings": {
        "clients": [
          { "id": "<UUID_BJ_HK>" }
        ],
        "decryption": "none"
      },
      "streamSettings": { "network": "tcp" }
    }
  ],
  "outbounds": [
    {
      "protocol": "freedom",
      "settings": {
        "redirect": "<美国服务器IP>:42371"
      }
    }
  ]
}
EOF

Note:

• Replace <UUID_BJ_HK> with the UUID generated during preparation.
• Replace <US Server IP> with the real public IP of your US server.

2.3 Start the Service

1
2

sudo systemctl enable --now xray
sudo systemctl status xray

Step 3: Configure the Domestic Entry Server (aliyun-bj)

The domestic server configuration remains unchanged, serving as the tunnel’s entry point.

3.1 Install Software and Enable BBR

Although the link from the domestic server to Hong Kong has low latency, enabling BBR can still improve performance under burst traffic.

1
2
3
4
5
6
7
8
9
10
11
12
13

# 适用于 Debian/Ubuntu
sudo apt update
sudo apt install -y xray

# 开启 BBR
sudo tee -a /etc/sysctl.conf > /dev/null << EOF
net.core.default_qdisc=fq
net.ipv4.tcp_congestion_control=bbr
EOF
sudo sysctl -p

# 验证 BBR 是否已开启 (输出应包含 bbr)
sysctl net.ipv4.tcp_congestion_control

3.2 Configure Xray

The dokodemo-door protocol is responsible for listening to UDP traffic from the client.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46

# 请确保已在准备工作中生成了 UUID_BJ_HK
# echo "北京 -> 香港 的 VLESS UUID: ${UUID_BJ_HK}"
sudo tee /usr/local/etc/xray/config.json > /dev/null << EOF
{
  "log": { "loglevel": "warning" },
  "inbounds": [
    {
      "port": 42371,
      "listen": "0.0.0.0",
      "protocol": "dokodemo-door",
      "settings": {
        "network": "udp",
        "address": "127.0.0.1"
      },
      "tag": "wg-in"
    }
  ],
  "outbounds": [
    {
      "protocol": "vless",
      "settings": {
        "vnext": [
          {
            "address": "<香港服务器IP>",
            "port": 8445,
            "users": [
              { "id": "<UUID_BJ_HK>" }
            ]
          }
        ]
      },
      "streamSettings": { "network": "tcp" },
      "tag": "hk-out"
    }
  ],
  "routing": {
    "rules": [
      {
        "type": "field",
        "inboundTag": ["wg-in"],
        "outboundTag": "hk-out"
      }
    ]
  }
}
EOF

Note:

• Replace <Hong Kong Server IP> with the real public IP of your Hong Kong server.
• Replace <UUID_BJ_HK> with the UUID generated during preparation.

3.3 Start the Service

1
2

sudo systemctl enable --now xray
sudo systemctl status xray

Step 4: Configure the Client and Connect

Now, everything is ready, just waiting for the final step.

4.1 Generate Client Keys Locally

On your Mac or Linux computer, execute:

1

wg genkey | tee client_private.key | wg pubkey > client_public.key

4.2 Add the Client as a Peer on the US Server

Log in to the US server and execute the following command to add the content of client_public.key generated in the previous step.

4.3 Create a Local WireGuard Configuration File

Create a us.conf file locally.

4.4 Connect!

Place the configuration file in a location where WireGuard can read it (such as /opt/homebrew/etc/wireguard/ on macOS), and then start it.

1

sudo wg-quick up us

Verification and Testing

After a successful connection, you can verify it in the following ways:

1. ping 8.8.8.8: Check basic connectivity.
2. curl ifconfig.me: Check if your outgoing IP has changed to the US server’s IP.
3. sudo wg show: Execute on both local and US servers to check latest handshake and transfer data to confirm if traffic is being transmitted.

Conclusion

Through a simplified three-hop architecture of Domestic -> Hong Kong -> USA, we successfully split an unstable, high packet loss long-distance link into two stable, high-quality short/mid-distance links. This new solution not only retains the original high stability and speed but also reduces latency and maintenance costs by simplifying the US server configuration.

So, how does this architecture perform in actual use? Let’s compare with a set of data. In the previous “Beijing direct to the USA” solution, network latency was about 170ms. After adding the Hong Kong relay, although the total latency slightly increased to about 200ms (an increase of 30ms, which is not noticeable in terms of user experience), it resulted in a significant improvement in stability and bandwidth. Previously, the download speed from Beijing directly to the USA fluctuated between 1MB/s and 5MB/s, and during peak times it could degrade to 100KB/s; under the new solution, the speed stabilizes between 10MB/s and 20MB/s. For latency-sensitive applications, such as real-time video calls, stability has also significantly improved, with almost no occurrences of stuttering or disconnections.

This once again proves that in complex network environments, the optimal solution is often not the shortest physical path, but the most efficient and stable logical path.