sing-box 家宽 IPv6 解锁流媒体失败？IP 被拉黑怎么办？

最近在折腾低成本解锁 Netflix 的方案，盯上了 AetherCloud 的家宽 IPv6。想着用 sing-box 做个分流，让流媒体走原生 IPv6 出站，既能省 CDN 钱，又能保证原生画质。结果现实很骨感，配置完后死活不通，AI 还在那一本正经地分析说我的 IP 被拉黑了。

这里把我的配置和排查思路写出来，给同样在踩坑的朋友们一点参考。

️ 配置核心思路

主要思路是利用 sing-box 的路由功能，把 Netflix 相关的流量通过指定的 IPv6 地址发出去。关键在于 outbounds 里的 inet6_bind_address 参数，这里绑定了脚本生成的家宽 IPv6。

先上配置（部分隐去）：

{
  "log": {"level": "info"},
  "dns": {
    "servers": [
      {"type": "tls", "tag": "google", "server": "8.8.8.8"},
      {"type": "tls", "tag": "cloudflare-v6", "server": "2606:4700:4700::1111"}
    ]
  },
  "inbounds": [
    {
      "type": "shadowsocks",
      "listen": "::",
      "listen_port": 8080,
      "network": "tcp",
      "method": "2022-blake3-aes-128-gcm",
      "password": "你的密码",
      "multiplex": {"enabled": true, "padding": true}
    }
  ],
  "outbounds": [
    {
      "type": "direct",
      "tag": "direct",
      "domain_resolver": {"server": "google", "strategy": "prefer_ipv4"}
    },
    {
      "type": "direct",
      "tag": "direct-v6",
      "inet6_bind_address": "2600:1700:aaaa:bbbb:cccc::dddd",
      "domain_resolver": {"server": "cloudflare-v6", "strategy": "ipv6_only"}
    }
  ],
  "route": {
    "rule_set": [
      {"type": "local", "tag": "geosite-netflix", "format": "binary", "path": "/etc/sing-box/rulesdat/geosite/netflix.srs"},
      {"type": "local", "tag": "geoip-netflix", "format": "binary", "path": "/etc/sing-box/rulesdat/geoip/netflix.srs"}
    ],
    "rules": [
      {"port": 53, "action": "hijack-dns"},
      {"rule_set": ["geoip-netflix", "geosite-netflix"], "outbound": "direct-v6"}
    ],
    "final": "direct"
  }
}

问题现象：家宽 IP ping 不通

按照配置启动后，流量看起来是路由过去了，但实际访问流媒体时无法连接。我在 VPS 上直接 ping 那个绑定的 IPv6 地址，结果是不通的。

为了验证，我把出站策略改回了默认的商宽 IPv6（没有绑定 inet6_bind_address 的原生出口）， Netflix 瞬间就通了。这基本排除了 sing-box 语法错误的问题。

️ 是 IP 被拉黑了吗？

最开始咨询了几个 AI 助手，它们给出的惊人一致结论是：IP 被拉黑了。

这种说法不是没有道理。公用家宽 IP（尤其是这种通过脚本批量获取的）因为共享用户多、行为不可控，很容易被流媒体服务商列入黑名单。一旦被标记，轻则无法解锁，重则直接阻断连接。

但是，除了“被拉黑”，其实还有几个可能被忽视的技术原因，建议大家在弃用这个 IP 之前，先排查一下：

排查与解决方案

1. 检查 VPS 的 IPv6 通告和路由

很多便宜 VPS 的 IPv6 配置并不规范。有时候你的 IP 是对的，但 VPS 本身没有正确配置路由表，或者这个 IPv6 前缀在 VPS 所在的子网里并不被上游网关接受。

验证方法：在 VPS 上抓包。
```
tcpdump -i eth0 icmp6
```
然后从本地 ping 那个 IPv6。如果 VPS 收到了请求但没回复，或者甚至没收到请求，那就是网络层面的路由问题，跟 IP 是否被封无关。
解决：检查 VPS 的 /etc/gated.conf 或 sysctl.conf 里的 net.ipv6.conf.all.forwarding 和 accept_ra 设置，必要时候开一下 NDP 代理。

2. MTU 问题导致的假性不通

IPv6 不像 IPv4 那样支持中间设备分片，如果 MTU 设置不当，大包会直接被丢弃，表现出来的现象往往是“小包能通（比如 ping 32 字节），大包挂掉（比如访问网页）”。

验证：
```
ping -c 4 -s 1472 <你的IPv6地址>
```
如果 1472 挂了但 32 正常，说明 MTU 太大。
解决：在 sing-box 的 outbound 配置里虽然没有直接调 MTU 的参数，但可以在系统层面调整网卡 MTU，或者在 sniff_override 里尝试调整 MSS（如果支持）。

3. IP 污染的应对策略

如果确实是因为 IP 被各大流媒体拉黑（这是最常见的情况），除了换 IP，还有几个野路子：

更换前缀：如果你用的是类似 AetherCloud 这种支持多前缀的服务，尝试换一个 /64 或 /60 的段。有时候是一个子段被拉黑，换一个就能复活。
使用 CDN 中转：如果 VPS 本身的 IPv6 没黑，只是家宽出口 IP 黑了，可以在 VPS 上搭建一个轻量级的反向代理，或者走 Cloudflare for SaaS 的套路，把流媒体请求“洗白”。不过这对 Netflix 这种强检测的 CDN 比较难，通常用于解锁其他区域限制内容。
转战 IPv4+WebSocket：如果 IPv6 实在太坑，不如老老实实走商宽的 IPv4 出口，配合 WebSocket 或者 gRPC 传输，虽然不是原生 IP，但胜在稳定。

写在最后

家宽 IPv6 确实是低成本解锁的神器，但从 VPS 出口的这一跳坑也不少。遇到问题别急着怪 IP 被封，先抓包，再查 MTU，最后再考虑换 IP。

不知道大家有没有遇到类似的情况？或者有更好的保号、洗 IP 骚操作？欢迎在评论区交流！