中国移动家宽访问普通海外 VPS 时，偶尔会遇到一个很典型的问题：服务器本身运行正常，其他网络可以连接，但移动家宽就是无法通过 IPv4 建立连接。本文记录一次真实排障：在不更换现有 RackNerd 洛杉矶 VPS 的前提下，利用移动家宽和服务器两端的原生 IPv6，最终让 Hysteria2 稳定播放 YouTube 4K。

问题背景

现有服务器位于 RackNerd 洛杉矶机房，普通国际 IPv4 线路在中国移动家宽下无法正常使用。最初考虑购买 CMIN2 优化线路 VPS，但在更换服务器前，先确认家宽是否具备原生 IPv6。

整个链路最终变成：

1
2
3
4
5
6
7
8
9
10
中国移动家宽
    │ 原生 IPv6
    ▼
Clash Verge Rev / Mihomo
    │ Hysteria2 UDP 443
    ▼
RackNerd 洛杉矶 VPS IPv6
    │
    ▼
Google / YouTube / 互联网

这里解决的是“客户端无法连接服务器”的问题。IPv6 并不会把普通国际线路变成 CMIN2，但可能绕过不可用的 IPv4 路径。

确认移动家宽支持 IPv6

macOS 自带的 ping 没有 -6 参数，应使用 ping6，或者直接向 IPv6 地址执行 ping：

1
ping6 -c 4 2606:4700:4700::1111

如果输出中同时满足以下条件，就具备 IPv6 出站能力：

  • 本机源地址是 2409: 等全球单播 IPv6，而不是 fe80:；
  • 能收到目标服务器的回复；
  • 系统存在 IPv6 默认路由。

查看本机 IPv6 地址和默认路由：

1
2
ifconfig | grep 'inet6 '
route -n get -inet6 default

常见地址类型：

1
2
3
4
2xxx: / 3xxx:  全球单播 IPv6，可以访问公网
fe80:          链路本地地址，不能代表公网 IPv6 可用
fc00: / fd00:  私有 IPv6
::1            本机回环地址

对于连接海外 VPS，只需要家宽具备 IPv6 出站能力，不需要让家庭设备开放 IPv6 入站端口。

向 RackNerd 申请 IPv6

RackNerd 的部分机房支持工单申请原生 IPv6。洛杉矶实例可以在客户中心选择 Technical Support，提交类似下面的内容：

1
2
3
4
5
6
7
8
9
10
11
Subject: Request Native IPv6 Allocation

Hello,

Please allocate one native IPv6 address to my Los Angeles VPS and provide
the IPv6 address, gateway, prefix length, and network configuration details.

Service ID: <YOUR_SERVICE_ID>
Main IPv4: <YOUR_IPV4>

Thank you.

本次工单提供了三个关键参数：

1
2
3
IPv6 address: <YOUR_IPV6>
Gateway:      <YOUR_IPV6_GATEWAY>
Netmask:      /64

公网地址、认证密码和私钥不应出现在公开文章或配置分享中，因此本文统一使用占位符。

在 Ubuntu 中持久化 IPv6

服务器系统是 Ubuntu 24.04，网卡名为 eth0，使用 Netplan。配置前必须先确认自己的网卡名和网络管理方式，不能直接假设所有服务器都叫 eth0：

1
2
3
4
5
cat /etc/os-release
ip -br addr
ip -4 route
ip -6 route
ls -la /etc/netplan

本次 SolusVM 已经自动把 IPv6 写入 /etc/netplan/50-cloud-init.yaml。结构如下：

1
2
3
4
5
6
7
8
9
10
11
12
network:
  version: 2
  ethernets:
    eth0:
      addresses:
        - <YOUR_IPV4>/<YOUR_IPV4_PREFIX>
        - <YOUR_IPV6>/64
      routes:
        - to: default
          via: <YOUR_IPV4_GATEWAY>
        - to: ::/0
          via: <YOUR_IPV6_GATEWAY>

使用静态 IPv6 地址和网关时，可以在 /etc/sysctl.d/99-racknerd-ipv6.conf 中关闭 SLAAC 和路由器通告，避免生成意外的动态地址或路由：

1
2
3
4
5
6
net.ipv6.conf.all.autoconf = 0
net.ipv6.conf.default.autoconf = 0
net.ipv6.conf.eth0.autoconf = 0
net.ipv6.conf.all.accept_ra = 0
net.ipv6.conf.default.accept_ra = 0
net.ipv6.conf.eth0.accept_ra = 0

应用这一个配置文件：

1
2
sysctl -p /etc/sysctl.d/99-racknerd-ipv6.conf
netplan generate

通过远程 SSH 修改网络时，不要贸然执行可能中断连接的命令。确实需要应用新 Netplan 配置时，优先使用可自动回滚的方式：

1
netplan try

检查地址和默认路由：

1
2
ip -6 addr show dev eth0 scope global
ip -6 route

测试服务器 IPv6 出站：

1
2
ping -6 -c 4 2606:4700:4700::1111
curl -6 --connect-timeout 10 https://icanhazip.com

curl 应返回刚申请的服务器 IPv6。

服务端协议与监听状态

这台服务器保留了两个入口：

1
2
Hysteria2  v2.9.2   UDP 443
sing-box   v1.13.14 TCP 8443，Reality

检查服务状态：

1
2
3
systemctl status hysteria-server sing-box --no-pager
systemctl is-enabled hysteria-server sing-box
systemctl is-active hysteria-server sing-box

检查 IPv6 监听：

1
ss -6 -lntup | grep -E ':(443|8443)'

预期结果是 Hysteria2 在 UDP 443 监听，sing-box 在 TCP 8443 监听。Hysteria2 的服务端配置位于：

1
/etc/hysteria/config.yaml

sing-box 配置位于：

1
/etc/sing-box/config.json

这些文件包含认证信息或密钥，只能通过安全渠道备份。

Clash Verge Rev 客户端配置

本地使用 Clash Verge Rev 和 Mihomo 核心。最终没有用 IPv6 节点替换 IPv4 节点，而是保留同一协议的两个入口：IPv6 网络优先使用 IPv6 地址，没有 IPv6 时仍可尝试 IPv4 地址。Reality 同样保留 IPv4、IPv6 两个手动节点，但不参加自动测速。

下面是最终生效配置的脱敏结构。真实密码、UUID、Reality 公钥和 Short ID 必须从现有可用配置或服务端安全读取，不能照抄占位符：

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
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
mixed-port: 7890
allow-lan: false
mode: rule
log-level: info
ipv6: false

proxies:
  - name: 洛杉矶-Hysteria2-IPv6
    type: hysteria2
    server: "<YOUR_IPV6>"
    port: 443
    password: "<HYSTERIA2_PASSWORD>"
    sni: "<YOUR_ORIGINAL_TLS_DOMAIN>"
    skip-cert-verify: false
    up: "100 Mbps"
    down: "200 Mbps"

  - name: 洛杉矶-Hysteria2-IPv4
    type: hysteria2
    server: "<YOUR_IPV4>"
    port: 443
    password: "<HYSTERIA2_PASSWORD>"
    sni: "<YOUR_ORIGINAL_TLS_DOMAIN>"
    skip-cert-verify: false
    up: "100 Mbps"
    down: "200 Mbps"

  - name: 洛杉矶-Reality-IPv6
    type: vless
    server: "<YOUR_IPV6>"
    port: 8443
    uuid: "<VLESS_UUID>"
    network: tcp
    tls: true
    servername: "<YOUR_REALITY_SERVER_NAME>"
    flow: xtls-rprx-vision
    client-fingerprint: chrome
    reality-opts:
      public-key: "<REALITY_PUBLIC_KEY>"
      short-id: "<REALITY_SHORT_ID>"

  - name: 洛杉矶-Reality-IPv4
    type: vless
    server: "<YOUR_IPV4>"
    port: 8443
    uuid: "<VLESS_UUID>"
    network: tcp
    tls: true
    servername: "<YOUR_REALITY_SERVER_NAME>"
    flow: xtls-rprx-vision
    client-fingerprint: chrome
    reality-opts:
      public-key: "<REALITY_PUBLIC_KEY>"
      short-id: "<REALITY_SHORT_ID>"

proxy-groups:
  - name: Proxy
    type: select
    proxies:
      - auto
      - 洛杉矶-Hysteria2-IPv6
      - 洛杉矶-Hysteria2-IPv4
      - 洛杉矶-Reality-IPv6
      - 洛杉矶-Reality-IPv4
      - DIRECT

  - name: auto
    type: url-test
    proxies:
      - 洛杉矶-Hysteria2-IPv6
      - 洛杉矶-Hysteria2-IPv4
    url: https://www.gstatic.com/generate_204
    interval: 180
    tolerance: 50

这里的 ipv6: false 沿用已经实测成功的 Profile。它不会阻止 Mihomo 连接 server 中直接填写的 IPv6 地址，主要影响域名解析相关的 IPv6 行为。国内域名和 IP 继续通过原 Profile 的 cn-domain、cn-ip 规则集直连，Google、OpenAI 及其余需要代理的流量进入 Proxy。

Hysteria2 密码字段的类型陷阱

服务端 /etc/hysteria/config.yaml 可能采用嵌套结构：

1
2
3
auth:
  type: password
  password: "<SERVER_PASSWORD>"

客户端不能把整个 auth 对象复制给 password。Mihomo 要求这里是单个字符串：

1
password: "<SERVER_PASSWORD>"

下面这种写法会直接导致 Clash Verge Rev 订阅校验失败：

1
2
3
password:
  type: password
  password: "<SERVER_PASSWORD>"

本次还出现过另一种更隐蔽的错误：字段类型是字符串，但内容并不等于服务端的 auth.password。这时 YAML 校验可以通过，Hysteria2 却会因认证失败而无法连接。因此自动生成客户端配置时，既要检查 password 的类型，也要确认其值来自正确的服务端字段。

需要特别注意：

  • server 和 port 分开填写时，IPv6 不加方括号；
  • 地址和端口写在同一个字符串中时，应使用 [IPv6]:443；
  • 实际连接地址可以改成 IPv6，但原来的 SNI 和 server_name 必须保留；
  • 不要无依据地强制增加 alpn: [h3]，优先沿用已验证配置；
  • 不要把 TLS 域名改成 IPv6，也不要为了省事关闭证书验证。

例如组合地址的形式：

1
[<YOUR_IPV6>]:443

修改 Profile 前应创建带时间戳的备份。Clash Verge 的订阅配置可能在自动更新时被覆盖，长期使用应关闭该 Profile 的自动更新，或者通过 Merge/覆写功能固定 IPv6 节点。

连通性与实际代理测试

先从客户端测试服务器 IPv6：

1
2
3
ping6 -c 20 <YOUR_IPV6>
traceroute6 -n <YOUR_IPV6>
nc -6 -vz <YOUR_IPV6> 8443

本次测试的 ICMPv6 结果并不好：

1
2
3
4
丢包率：20%～25%
平均延迟：约 260～275ms
最低延迟：约 227ms
最高延迟：约 405ms

服务器端网卡没有错误或丢弃，ICMPv6 也没有触发本机限速，说明丢包发生在移动到 RackNerd 的国际路径中。但 ping 不是最终结论，还要测试真实代理流量。

本次最终配置的本地 mixed-port 是 7890，通过 SOCKS5 连续测试 Google：

1
2
3
4
5
6
7
curl --socks5-hostname 127.0.0.1:7890 \
  --connect-timeout 10 \
  --max-time 30 \
  -o /dev/null \
  -sS \
  -w 'HTTP=%{http_code} total=%{time_total}s speed=%{speed_download}B/s\n' \
  https://www.google.com/generate_204

正常结果应为：

1
HTTP=204

进行约 20MB 下载测试：

1
2
3
4
5
6
7
curl --socks5-hostname 127.0.0.1:7890 \
  --connect-timeout 10 \
  --max-time 60 \
  -o /dev/null \
  -sS \
  -w 'HTTP=%{http_code} total=%{time_total}s speed=%{speed_download}B/s\n' \
  'https://speed.cloudflare.com/__down?bytes=20000000'

Hysteria2 与 Reality 的实测对比

同一条 IPv6 路径下，两个协议的表现差异非常明显：

指标 Hysteria2 IPv6 Reality IPv6
Google 连续测试 10/10，成功率 100% 5/10，成功率 50%
失败表现 无 SSL 握手错误或超时
20MB 下载 约 2.08 MB/s，9.59 秒完成 60 秒仅约 744KB
实际体验 YouTube 4K 正常播放 不适合作为默认节点

这次结果说明，线路虽然存在较高丢包，但 Hysteria2 的 UDP/QUIC 传输对丢包的适应能力明显好于基于 TCP 的 Reality。最终配置把 Hysteria2 IPv6 和 IPv4 放入 auto 测速组，Reality IPv6 和 IPv4 留在手动选择列表中作为排障备用。移动家宽通常会选中可达的 IPv6 节点；IPv4-only 网络则会尝试 IPv4 节点，但是否可用仍取决于当地线路。

在其他设备上复用

新增电脑或手机前，先确认该设备所在网络具备 IPv6：

1
ping6 -c 4 2606:4700:4700::1111

Windows 使用：

1
ping -6 2606:4700:4700::1111

然后选择一种方式：

  1. 通过 AirDrop、加密 U 盘或可信的端到端加密渠道，复制现有 Clash Profile；
  2. 只从现有配置复制完整的 Hysteria2 节点块，保留全部认证和 TLS 参数；
  3. 导入支持 Mihomo/Hysteria2 的客户端；
  4. 选择 Proxy → auto，开启系统代理或 TUN 模式；
  5. 使用 Google generate_204 和 YouTube 进行实际验证；
  6. 保留原 IPv4 节点作为没有 IPv6 时的备用方案。

如果新网络没有 IPv6，原始 IPv6 地址无法直接连接。域名解析也不能凭空为 IPv4-only 网络提供 IPv6 能力，此时仍需可用的 IPv4 节点、中转或其他双栈入口。

日常排障命令

查看服务器 IPv6：

1
2
ip -6 addr show dev eth0
ip -6 route

查看服务和监听端口：

1
2
systemctl status hysteria-server sing-box --no-pager
ss -lntup | grep -E ':(443|8443)'

查看 Hysteria2 日志：

1
journalctl -u hysteria-server -n 100 --no-pager

必要时重启服务：

1
systemctl restart hysteria-server

如果 TCP 端口能建立连接，但 Hysteria2 仍不可用，应重点检查 UDP 443、客户端认证、SNI、系统时间和实际加载的 Profile，而不是只看 TCP nc 结果。

总结

本次问题最终没有通过购买新服务器解决，而是利用现有移动家宽和 RackNerd 的原生 IPv6，绕过了无法连接的 IPv4 路径。虽然国际 IPv6 路由存在 20%～25% 的 ICMP 丢包，Hysteria2 仍实现了 Google 连续请求 100% 成功、约 16.6Mbps 下载速度，并能够正常播放 YouTube 4K。

选择跨境 VPS 时，CMIN2 依然是中国移动用户更稳定的线路方案；但在现有 VPS 支持 IPv6、客户端网络也有 IPv6 的情况下，先申请并测试免费原生 IPv6，往往是成本最低的排障顺序。

最后，节点配置只能用于自己的受控设备，不要开放成公共代理；配置文件、认证密码、TLS 私钥和 SSH 私钥都应安全保存，并遵守所在地法律及服务商的使用条款。