巧用香港中转,搭建丝滑稳定的中美三层隧道
在之前的文章《搭建全程美国 IP、无需手动设置代理的三层隧道》中,我们通过 国内服务器 -> 美国服务器
的架构,解决了访问全球服务时遇到的诸多网络问题。但一个新的性能瓶颈逐渐显现:国内服务器与美国服务器之间的公网连接,在高峰时段延迟高、丢包严重。
这导致即便我们使用了隧道,依然会遇到 SSH 操作卡顿、在线会议掉线、API 请求超时等问题。根本原因在于中美之间的国际互联网链路,如同一条节假日的高速公路,拥堵是常态。
面对这个问题,一个反直觉的解决方案浮出水面:如果直路不通,我们绕路走会不会更快?
核心洞察:为什么增加一跳,反而更快?
答案是肯定的,前提是“绕”得聪明。我们选择的“绕行路线”是香港。
这个选择基于一个关键洞察:链路的整体性能取决于其最薄弱的一环。国内 -> 美国
这条链路的瓶颈,恰恰是跨越太平洋的这段公网。
而增加香港作为中转站,我们将一条不稳定的长途链路,拆分成了两条高质量的链路:
- 国内 -> 香港:物理距离近,网络基建好,有大量云服务商提供低延迟、高稳定的专线级连接。
- 香港 -> 美国:香港作为亚洲的顶级网络枢纽,拥有充裕的国际出口带宽和到美国的高质量海底光缆。
最终,国内 -> 香港 -> 美国
这条“折线”虽然多了一个节点,但每一段都如同行驶在 VIP 车道上,其综合速度和稳定性远超拥堵的“直线”路径。我们用一点点几乎可以忽略不计的转发延迟,换来了稳定性和吞吐量的大幅提升。
巧用香港中转
我们将搭建如下的数据链路。
你的设备 (WireGuard)
→ 国内服务器 (Xray)
→ 香港服务器 (Xray)
→ 美国服务器 (WireGuard)
→ 互联网
你可能会问:为什么不直接从我的设备连接到香港服务器,而要增加一个国内服务器作为跳板?
答案在于“第一公里”的网络质量。我们个人的家庭宽带或移动网络,在访问境外服务器(包括香港)时,稳定性难以保障,尤其是在网络高峰期。而国内的云服务商(如阿里云、腾讯云、华为云等)的数据中心之间,特别是主流节点(如北京、上海、广州)到香港的线路,通常经过了专门优化,甚至一些有资质的公司可以租用专线连接。这确保了从国内服务器到香港服务器这一段路的稳定和低延迟。因此,我们将国内服务器作为隧道的入口,就能有效规避个人网络环境的波动,将我们的数据流量第一时间送上最可靠的“高速公路”。
数据流解析:
- 设备到国内服务器: 你的电脑或手机作为 WireGuard 客户端,将所有网络数据(UDP 包)发送到国内服务器的特定端口。
- 国内服务器到香港服务器: 国内服务器上的 Xray 服务接收 UDP 包,通过 VLESS 协议将其伪装并封装在一条稳定的 TCP 连接中,发往香港。
- 香港服务器到美国服务器: 香港服务器是关键的中转站。它接收来自国内的 VLESS 数据流,解包出原始的 WireGuard UDP 包,然后直接将这个 UDP 包转发到美国服务器的 WireGuard 端口。
- 美国服务器到互联网: 美国服务器是隧道的终点,它只运行 WireGuard 服务。它接收到香港发来的 UDP 包,处理后将你的流量从美国 IP “送出”,实现对全球互联网的访问。
准备工作
- 三台服务器:
- 国内服务器(北京/上海/广州等,本文以
aliyun-bj
为例) - 香港服务器(本文以
aliyun-hk
为例) - 美国服务器(本文以
us-west
为例)
- 国内服务器(北京/上海/广州等,本文以
- 软件:
- 国内和香港服务器需要安装
Xray
。 - 美国服务器只需要安装
WireGuard
。
- 国内和香港服务器需要安装
- UUID: 我们需要为
国内 -> 香港
的 VLESS 连接生成一个 ID。请提前生成并记录下来:1
2
3
4# 用于国内 -> 香港
export UUID_BJ_HK=$(uuidgen)
echo "北京 -> 香港 的 VLESS UUID: ${UUID_BJ_HK}"
防火墙配置
在开始配置服务之前,请确保你已经在服务商的控制台(如阿里云/腾讯云/AWS安全组)或在服务器内部(如 ufw
, firewalld
)为每台服务器放行了必要的端口。这是保证隧道联通的关键一步。
美国服务器 (us-west):
- 入口规则: 允许来自香港服务器 IP 的 UDP 流量进入端口
42371
。 - 说明: 这是 WireGuard 服务监听的端口。为了安全,建议只允许来自香港服务器的 IP 访问。
- 入口规则: 允许来自香港服务器 IP 的 UDP 流量进入端口
香港服务器 (aliyun-hk):
- 入口规则: 允许来自国内服务器 IP 的 TCP 流量进入端口
8445
。 - 说明: 这是 VLESS 服务监听的端口,用于接收来自国内服务器的数据。
- 入口规则: 允许来自国内服务器 IP 的 TCP 流量进入端口
国内服务器 (aliyun-bj):
- 入口规则: 允许来自你的本地网络的 UDP 流量进入端口
42371
。 - 说明: 这是隧道的总入口,WireGuard 客户端将连接此端口。如果你的本地 IP 不固定,可以设置为
0.0.0.0/0
(任意来源),但这会稍微降低安全性。
- 入口规则: 允许来自你的本地网络的 UDP 流量进入端口
分步配置实战
第一步:配置美国终点服务器 (us-west)
美国服务器现在是纯粹的 WireGuard 终点,配置极其简单。
1.1 安装软件并开启 BBR
BBR 是 Google 开发的 TCP 拥塞控制算法,可以显著提升服务器的 TCP 性能。
1 | # 适用于 Debian/Ubuntu |
1.2 配置 WireGuard (wg1)
首先,生成 WireGuard 接口 wg1
的密钥对。
1 | sudo wg genkey | sudo tee /etc/wireguard/wg1_private.key | sudo wg pubkey | sudo tee /etc/wireguard/wg1_public.key |
然后,创建配置文件 /etc/wireguard/wg1.conf
。
1 | # 获取你的私钥 |
注意: PostUp
/PostDown
中的 eth0
是你服务器的公网网卡名,请根据 ip addr
的显示结果自行修改。
1.3 启动服务
1 | # 开启内核 IP 转发 |
第二步:配置香港中转服务器 (aliyun-hk)
香港服务器作为“二传手”,负责解包并转发流量。
2.1 安装软件并开启 BBR
香港服务器作为 TCP 隧道的中转点,开启 BBR 对优化国内到香港的 VLESS 连接至关重要。
1 | # 适用于 Debian/Ubuntu |
2.2 配置 Xray
一个 VLESS 入口(接收国内数据),一个 Freedom 出口(直接转发 UDP 到美国)。
1 | # 请确保已在准备工作中生成了 UUID_BJ_HK |
注意:
- 将
<UUID_BJ_HK>
替换为你准备工作中生成的 UUID。 - 将
<美国服务器IP>
替换为你的美国服务器的真实公网 IP。
2.3 启动服务
1 | sudo systemctl enable --now xray |
第三步:配置国内入口服务器 (aliyun-bj)
国内服务器配置不变,是隧道的入口。
3.1 安装软件并开启 BBR
国内服务器到香港的链路虽然延迟低,但开启 BBR 依然能提升突发流量下的性能。
1 | # 适用于 Debian/Ubuntu |
3.2 配置 Xray
dokodemo-door
协议负责监听来自客户端的 UDP 流量。
1 | # 请确保已在准备工作中生成了 UUID_BJ_HK |
注意:
- 将
<香港服务器IP>
替换为你的香港服务器的真实公网 IP。 - 将
<UUID_BJ_HK>
替换为准备工作中生成的 UUID。
3.3 启动服务
1 | sudo systemctl enable --now xray |
第四步:配置客户端并连接
现在,万事俱备,只欠东风。
4.1 在本地生成客户端密钥
在你的 Mac 或 Linux 电脑上执行:
1 | wg genkey | tee client_private.key | wg pubkey > client_public.key |
4.2 将客户端添加为美国服务器的 Peer
登录到美国服务器,执行以下命令,将上一步生成的 client_public.key
内容添加进去。
1 | CLIENT_PUBLIC_KEY=$(cat client_public.key) |
4.3 创建本地 WireGuard 配置文件
在本地创建 us.conf
文件。
1 | [Interface] |
4.4 连接!
将配置文件放到 WireGuard 能读取到的位置(如 macOS 的 /opt/homebrew/etc/wireguard/
),然后启动。
1 | sudo wg-quick up us |
验证与测试
连接成功后,可通过以下方式验证:
ping 8.8.8.8
: 检查基本连通性。curl ifconfig.me
: 查看你的出口 IP 是否已经变为美国服务器的 IP。sudo wg show
: 在本地和美国服务器上执行,查看latest handshake
和transfer
数据,确认流量是否在传输。
结语
通过 国内 -> 香港 -> 美国
的精简版三级跳架构,我们成功地将一条不稳定、高丢包率的长途链路,拆分成了两条稳定、高质量的短途/中途链路。这个新方案不仅保留了原有的高稳定性和速度,还通过简化美国服务器的配置,降低了延迟和维护成本。
那么,这种架构在实际使用中效果如何?我们用一组数据来直观对比。在之前的“北京直连美国”方案中,网络延迟大约在 170ms。而在增加了香港中转后,虽然总延迟略微增加到约 200ms(增加了 30ms,在体感上并不明显),但换来的是稳定性和带宽的巨大提升。之前北京直连美国的下载速度在 1MB/s 到 5MB/s 之间波动,高峰期甚至会劣化到 100KB/s;而新方案下的速度则稳定在 10MB/s 到 20MB/s。对于延迟敏感的应用,如实时视频通话,稳定性也得到了显著改善,卡顿和掉线的情况几乎不再发生。
这再次证明了在复杂的网络环境中,最优解往往不是最短的物理路径,而是最高效、最稳定的逻辑路径。