联通 IPv6 打不通，客服只会说「你家没有公网 IP」

昨晚七点多，我蹲在路由器旁边盯着 tcpdump 滚屏。同一台 NAS、同一个端口，两个不同的来源，走向完全相反。一边三次握手干净利落。另一边——包进来了，我家也把回包发出去了。然后就没有然后了。

起因很普通：我家宽带的 IPv6，用手机连不上。找联通，客服很客气，也很熟练。三句话之内一定会给我一句「你家没有公网 IP」，然后这通电话就算走完了、没有任何下文。我一开始还认真解释，解释到第三次我明白了：这句话跟我的问题没关系，它只是话术本上的终止符，只是客服为了完成工单而已。

流程没什么毛病，态度也一直很好。只是从头到尾，没有人问过一句「包到底走到哪儿了」。我也理解一线客服没有抓包权限，不指望他们当场判断。但正因如此，这件事只能靠用户自己，把证据做到「不需要对方懂网络也能看明白」的程度。这也是我写这篇的原因。

所以我把证据做成了没法绕开的形式——下面每个数字都是我自己抓包分析出来的，pcap 文件还在硬盘上躺着。

先说结论

问题不是「我家没有公网 IP」。是「家宽 → 手机」这个方向的回包，在运营商网络里消失了。

同一台 NAS、同一个端口 9443，只换来源：从腾讯云（跨运营商的数据中心）发起——三次握手完整、TLS 正常、下载跑满 115 Mbps。从联通蜂窝手机发起——手机发出的 SYN 全部到达我家，我家逐条回了 SYN-ACK，手机收到的 ACK 是 0。这个 0 不是某一次的偶然：换着窗口抓了几轮，入向 SYN 从 93 到 17 不等（取决于当时抓了多久），回向 ACK 一直是 0。

后来我又换 UDP 重测了一遍——17 个请求全部到达我家，我家回了 17 个应答，手机收到 0 个。换个协议，什么都没改变。

再后来我把手机里的卡也换了一张：同一台手机，联通卡换成电信卡，结果两张卡的 ACK 都是 0（同一次抓包里，联通卡 17 进 29 出、电信卡 9 进 11 出，合计 26 进 40 出、0 回）。连「换个运营商就好了」这条退路，也一起堵死了。

我不太喜欢「被封了」这种说法。它太笼统，笼统到没法反驳，也没法验证；而一个说清楚了方向、说清楚了两端网络、说清楚了计数的事实，才是有用的东西。

而且我并不是第一个撞上的人。V2EX 上早就有联通的用户发帖问「联通家宽 IPv6 无法接受入站 TCP 请求？」——标题跟我这次的症状几乎一字不差。下面那句回帖更扎心：「联通的一定要改桥接，因为他们的光猫配置有问题」。也就是说，这种事用户早就学会自己绕了，而不是等运营商给个解释。

说句糙话：干这种不干人事的事，他们也不是一次两次了。既不发公告、也不给理由，用户只能自己猜；猜不出来，就自己认栽，或者自己找梯子翻墙绕过去。

先把一句话说清楚：我不认为「封端口」本身就是罪。家宽默认封掉入站 80/443 有它的道理——防止有人拿家宽搭没备案的网站，这条我认。但我用的是 9443，一个高位端口。更要命的是，回包根本回不来。这就不在「防建站」的解释范围里了。

更关键的是下面这两组地址。我用来做对照的两端，本来都属于联通：

网络	IPv6 段	APNIC 登记归属
我家宽带（联通固网）	2408:8256::/32	CU-CN / China Unicom
我的手机·联通卡（联通蜂窝）	2408:8459::/32	CU-CN / China Unicom
我的手机·电信卡（电信蜂窝）	240e:47c::/32	China Telecom

前两段同属 2408:8000::/20，一个注册记录。也就是说，从我家门口到手机，全程都在联通自己的网里——「跨运营商互联互通」这个借口在这里用不上。第三行是后来补的对照：换成完全另一家运营商的卡，结果一样，所以这个借口连「换一家试试」都躲不过去。

两分钟基础：怎么从抓包里直接读出结论

网络是分层的，一共五层。这个不用记，只要知道一件事：如果对方的包已经出现在我的抓包里，下面三层（物理、数据链路、网络）就已经被证明是通的——包要跨过对端网络、越过运营商线路、落在我的网卡上，中间断任何一段，我都抓不到它。

剩下两层里，应用层是好的（外网连 NAS 能拿到真实响应、下载跑满 115 Mbps）。所以只剩一个地方可疑：握手能不能走完。

TCP 建连接要三步。像打电话：你问「在吗」，对面说「在，你听得到我吗」，你再回一句「听到了」。关键在第三步必须由发起方发出。少这一步，你那头就只能一直以为对面没接电话，然后反复重拨，直到超时。

为什么非得三步、两步不行？因为网络里的包会丢、会重复、会乱序，两次没法让双方都确认「对方确实听到了自己」，三次是能同时满足两边的最小次数。这也顺便解释了为什么我家会看到 93 个 SYN：手机不是在攻击我，它只是在不停地重试。

所以后面那些抓包就好读了：SYN 到了、SYN-ACK 回了、ACK 没到。

我是怎么测的（以及为什么这次的数据比较难赖）

先交代拓扑。我家光猫是桥接的，PPPoE 拨号由软路由自己完成（iStoreOS，跑在 eth0 上）。这意味着我家 IPv6 入站的守门人就是这台软路由，不存在「光猫偷偷拦了、我查不到」这种没法定论的说法。

我一开始也走过弯路：先测一次「外网能不能连进来」，再测一次「手机能不能连进来」，然后拿两份结果去对比。这种方法不严谨——两次抓包的时间、来源端口、经过的路径都可能不同，对方一句「你这两次条件不一样」就能把结论顶回来。

后来我把方法改成：抓包点固定在同一个网口，目标固定为同一台机器的同一个端口，唯一变量是来源网络。两组数据落在同一份抓包里，条件不一致这个借口就没了。

顺便说一句，在自己家做这些测试的时候我有点荒诞感：我在费劲证明一件本该是默认功能的事——我家的网，我能不能从外面连进来。

具体做法是在软路由上抓，命令行大概长这样。关键参数是 -i any 和事后用 -e 打印接口与方向——只抓一个口的话，你只能看到「包到了」或者「包没到」，看不到它是怎么走的：

# 抓包：只按时长跑，不要设置包数上限（我在这上面栽过，见下文）
tcpdump -i any -n -s 0 -w /tmp/cap.pcap 'ip6 and tcp and host <对端地址>'

# 回读：-e 打印接口与方向，这是判断「包死在哪一跳」的关键
tcpdump -enr /tmp/cap.pcap

之所以强调「按时长跑」：我第一版脚本设了抓满 600 个包就退出，结果一波背景扫描流量三十秒就把名额占满，抓包提前结束，而我的测试在几分钟后才做——那次结论完全无效。

证据一：同一把尺子，两组回显

A 路（对照组）的原始回显：

19:16:57.911809  In  ...10c6:0.58514 > ...b9c:10f0::xxx.9443: Flags [S]
19:16:57.912035  Out ...b9c:10f0::xxx.9443 > ...10c6:0.58514: Flags [S.]
19:16:57.917095  In  ...10c6:0.58514 > ...b9c:10f0::xxx.9443: Flags [.]
19:16:57.917459  Out ...b9c:10f0::xxx.9443 > ...10c6:0.58514: Flags [F.]

这三行学过网络的都认：[S] 是发起、[S.] 是对端应答、[.] 是我这边确认。三次握手在本侧完整走完，后面还有数据 PSH 交换和 FIN 四次挥手，是一条全程正常的连接。

B 路（故障组）的原始回显。这里我把抓包点扩展到了三个接口，好让「包走到哪一步」变得可见：

19:10:11.206444  pppoe-wan In   手机.58614 > NAS.9443   Flags [S]
19:10:11.206484  br-lan    Out  手机.58614 > NAS.9443   Flags [S]
19:10:11.206487  eth2      Out  手机.58614 > NAS.9443   Flags [S]
19:10:11.206829  eth2      P    NAS.9443 > 手机.58614   Flags [S.]
19:10:11.206927  pppoe-wan Out  NAS.9443 > 手机.58614   Flags [S.]

五行读下来：手机的包进了我家入口，被转发到内网，送到了 NAS 的网口。NAS 回了 SYN-ACK，回包也真的从我家宽带的出口发出去了。然后就停在这儿了——手机那边翻来覆去重传同一个 SYN，因为在它看来，对面从来没答应过。

所以现在每次有人跟我说「你家网络有问题」，我都想把这几行打印出来贴他脸上。

再补一个容易被忽略的细节：这两组回显的时间相差大约六分钟，但目标、端口、抓包位置完全一致。这就是我说「同一把尺子」的意思。换来源，不换别的。至于为什么非得这么较真，是因为我第一次跟客服沟通时就吃过亏——对方回我一句「你这两次测的条件不一样吧」，我当场没法反驳，因为确实不一样。

证据二：三行计数就够了

计数项	A 路 · 云服务器	B 路 · 联通蜂窝手机
入向 SYN（对端发出，含重传）	8	93
出向 SYN-ACK（我家应答）	8	134
入向 ACK（对端确认收到应答）	26	0
出向 PSH（数据）	21	0
入向 FIN（正常挥手）	7	0

A 路那 26 个 ACK 说明对端确实收到了我家的应答；B 路那 0 个 ACK 说明手机一个都没收到。

这三行数字摆在一起，指向非常单一：问题不在我家这一侧，也不在地址本身。是这条回程路上的数据包，被联通拦了。

多说一句这个 0 为什么关键。TCP 是个有状态的协议，握手要三方都参与：对端发出请求，我方应答，对端再确认一次。只要最后那一步没完成，连接对两端来说就等于没建立——所以手机上的表现是「一直转圈」，而不是「拒绝连接」。

反过来，如果问题出在我家的防火墙，你家设备会主动回一个「拒绝」，浏览器的报错文案会完全不同。这两种失败在用户眼里都是「打不开」，抓包里却是两件截然不同的事。

证据二·补：换两张卡，还是同一个 0

上面那条 B 路用的是联通自己的卡。这里有个可以立刻推翻的辩解：会不会只是「联通卡连联通家宽」这条组合有问题？那就换一张别的运营商的卡试试——这是能直接证伪的实验，不做没道理。

我手边正好有一张电信卡，插进同一台手机，同一个网址再访问一次。为了不给「时间点不一样」留下借口，这次我把两张卡挤在同一次抓包里：先点联通卡访问，再换卡点电信访问，中间不关抓包。这样两组数据的抓包点、目标、端口、时间窗口全都一致。

运营商	连接数	入向 SYN	出向 SYN-ACK	手机回传 ACK
联通蜂窝	3	17	29	0
电信蜂窝	2	9	11	0
合计	5	26	40	0

两张卡的计数分开看：联通卡 17 进、29 出、0 回；电信卡 9 进、11 出、0 回。同一个 0。

这一步的价值不在数字更大，而在它把「目的地运营商」这个变量直接删掉了。手机换成电信的卡，目标还是我家那个联通地址，结果一模一样——说明问题跟手机是谁家的、卡是哪个运营商发的都没关系。换卡没用，这一点我先替你试过了。

顺带说清楚：这也堵死了另一个说法。「你手机是联通的，联通自己内部限制而已」——不成立，因为电信卡在同一个位置、同一个网络里，表现完全相同。

证据二·补二：同一天，机房源隔几分钟刚连通过

只做手机侧的测试还不够，因为总有人可以说「也许你家 NAS 今天就是不正常」。所以这两次手机测试之前，我在同一天、同一台 NAS、同一个端口上，先用腾讯云（机房源）跑了一遍完整对照：

发起方	NAS:9443 实测结果
腾讯云（机房源）	ICMP 5/5 0% 丢包；TCP 9999 / 9443 / 80 / 443 全部 OPEN；HTTPS 返回 HTTP 307 / 23ms
两卡手机（蜂窝端）	26 个 SYN 到达、40 个 SYN-ACK 发出、0 个 ACK 回来

时间上是这样的：机房源那三次握手干净利落、下载跑满，隔了没几分钟，手机端在同一个端口上连三次握手第二步都走不完。同一台机器，一边是完整的 HTTP 会话，一边是永远缺最后一步的握手中断——NAS 自己没有任何变化，变的只有来源网络。

所以到这里，三个变量（目的运营商、手机设备、服务端）都排掉了，剩下来的只有一个：发起方是住宅源还是机房源。

证据三：先把自家摘干净

测别人之前先自证，这是我的习惯。下面每一项都是实测，不是「按理说应该没问题」。

先自证不是为了讲道理，是为了让「这不怪你家」这句话没法被反驳。

检查项	实测结果
软路由防火墙	已按最小权限放通 NAS 指定端口，从公网实测可连；445/2049 等高危口故意不开
家宽上行带宽	104 / 104 / 106 Mbps（三次，对端逐字节校验）
IPv6 直连下载	50MB 用 3.6 秒，约 115 Mbps
TCP / TLS / 首字节	4.9ms / 16.9ms / 21.9ms
ICMPv6 时延与丢包	4.8ms，0% 丢包
PMTU	1464，无 MTU 黑洞
域名解析	只有 AAAA 记录，无多余的 A 记录
手机侧 IPv6 出网	在线自测 9/10，手机自己有 IPv6

那一列数字里，115 Mbps 不是估的：我让 NAS 主动往云服务器推 40MB，在云服务器上用 wc -c 数字节确认实际收到多少。为什么要一项项排除？因为「连不上」和「连得慢」是两类完全不同的问题，混在一起就永远谈不清楚。带宽不够、时延高、丢包、MTU 黑洞、解析错误，这几个都会让用户感觉「网络有问题」——但只有把它们的嫌疑逐个排掉，剩下的那个「方向不通」才站得住。

另外有一件事我特意先做了：确认自己的地址是当前有效的那个。家用宽带的 IPv6 前缀会跟着 PPPoE 重拨变化，旧地址在一段时间里还挂在网卡上，但已经不通了。拿一个失效的地址去测，结果就是 100% 丢包——看起来和「被封了」一模一样。我第一次就踩了这个坑：我家宽带在那两次测试之间重拨过一次，前缀从一段换成了另一段，我用的是旧地址。那一整轮结论翻来覆去，全是白折腾。

证据四：换个协议再测一次，结论一个字都没变

上面这些证据有个共同的漏洞，我自己得先点出来：全是 TCP。那如果对方只对 TCP 做了手脚呢？那我的结论就下早了。

所以我拿 UDP 又测了一遍。选它是有理由的：它连握手都没有，失败是完全无声的——TCP 好歹会回你一个「拒绝」，UDP 连这个都不给。也就是说，拿 UDP 测，「没看到回应」这四个字完全不能当结论用，只能两边同时抓包，看包究竟走到哪一步没了。做法还是老规矩，唯一变量是协议：同一台 NAS、同一个家宽出口抓包点、同一个方向（手机 → 家宽）。

# 手机上点下测试之后，我家出口抓到的 UDP（节选）
21:05:51.547  In  手机.34587 > ::378.9878  UDP, length 20   <- 请求到达
21:05:51.548  Out ::378.9878 > 手机.34587  UDP, length 68   <- 家里立刻回了
...
21:06:37.531  In  手机.37670 > ::378.9878  UDP, length 20
21:06:37.532  Out ::378.9878 > 手机.37670  UDP, length 68

# 合计：17 个请求 / 17 个应答 / 手机收到 0 个
# 回包校验和错误：0（排除「回包本身是坏的」这条）

手机上点下测试之后，家里一共收到 17 个 UDP 请求，回了 17 个应答，手机收到 0 个。我还顺手查了回包的校验和，0 个错误——把「回包本身是坏的、所以被对端丢掉」这条也排除掉了。这件事的分量在这里：TCP 要三次握手，UDP 连握手都没有。两套机制几乎找不到共同点，可它们在同一个方向上的表现逐条一致。

所以我把结论改成了「不是某个协议被限制，而是这个方向上的包在丢」。这不是为了显得严谨——恰恰是这句话把结论钉得更死。对方再想说「没封 TCP」，这句话连提出来都不成立了。顺手把第三个协议也测了：ICMPv6，就是 ping。不过方向是反的，从我家往手机打——5 个包，0 个回应。同一个方向，同一件事。

最后交代一个插曲，因为它是这类测试最容易把人带偏的地方：这个 UDP 测试第一次跑出来是失败的，但原因在我这边。我的 NAS 有两张网卡，回包从另一张网卡的地址出去了；而浏览器会校验「回应是不是来自我请求的那个地址」，对不上就直接丢掉。改成从请求进来的那个地址回包，才是真实结果。测试工具自己造成的失败，比网络问题更容易让人走错路。这也是这两天最深的体会——每一句「不通」，都得先问一遍：是不是我自己这边弄错了。

再讲一层背景：IPv6 和 IPv4 是两套东西

不讲技术细节，这件事说不清楚，所以这里只花四段。

IPv4 的问题是地址不够。全世界能分的 IPv4 地址早就发完了，所以运营商的做法是：给一整个小区或一整片用户共用一个出口地址，你家设备拿到的是内网地址，对外靠运营商做地址转换。这种机制叫 NAT。用户嫌麻烦、想从外面连回家，这就是「申请公网 IP」这个业务的由来。

IPv6 不存在这个问题，因为它没有 NAT。运营商直接给你一段 /64 的前缀，长度是 1844 亿亿个地址——你家路由器再从这段前缀里给每台设备分地址，分出去的每一个都是全球可路由的。没有转换，就没有「公网 / 内网」这一说。

顺带一个常被误解的点：IPv6 里「端口转发」这个概念根本不存在，因为不需要转发。一台设备有了全球可路由的地址之后，能不能从外面进来只看一件事——你家防火墙放不放行。这也是为什么「我开了 UPnP 为什么没用」这类问题的答案是：UPnP 是 IPv4 NAT 时代的产物，它管不到 IPv6。

说难听点，那套话术之所以能一直用下去，就是赌你不知道这两者的区别。

「你家没有公网 IP」这句话为什么答非所问？

先说明一件事：我不是在要公网 IPv4，我说的是 IPv6。这两套体系在排障上完全是两回事。「公网 IP」是 IPv4 时代的说法。因为 IPv4 地址不够用，运营商用 NAT 把一大堆用户塞进一个出口地址里，你从外面确实进不来。IPv6 没有 NAT，地址管够，运营商直接给你发一个 /64 前缀，里面每个地址都是全球可路由的。

所以当客服说「你家没有公网 IP」时，他回答的是另一个问题。而这件事不需要我费口舌解释，实测就能反驳：

• 我家那个 IPv6 地址是联通通过 PPPoE 下发的，不是 fd00::/8 这种内网地址，也不是 fe80:: 这种链路本地地址；
• 我从一台外部云服务器直接连进了这个地址，握手成功、拿到真实响应、下载跑满 115 Mbps。如果我家「没有公网 IP」，这件事不可能发生；
• 反方向也佐证了同一件事：手机发来的 93 个 SYN 全部到达我家入口，入站是通的。这跟「没有公网 IP」自相矛盾；
• 至于 IPv4，我家宽带出口确实在运营商的大内网里（CGNAT），但那是另一个问题，跟 IPv6 通不通没有半点关系。

说到底，能不能从外面连进来，IPv4 看的是「有没有公网地址」，IPv6 只看一件事：防火墙放不放行。拿 IPv4 的答案去结 IPv6 的工单，就是驴头不对马嘴。

再补一句给这套话术：就算拿到了公网 IPv4，也不等于端口就放开了。业内都知道，公网地址只是端到端可达的前提，入站照样会被局端的 ACL 拦下来——这是两套各自独立的策略。拿「有没有公网地址」去回答「IPv6 通不通」，等于答错了科目。

说白了，这也不怪客服，因为客服联通压根就没好好培训。当时我也入职过联通，在联通实习过一段时间，是一家叫《中通文博》的外包公司培训的。当时是怎么培训的呢？总共14天，12天在营销，只有一天在讲技术，最后一天考试。完全不培训关于计算机网络的知识，如果你没有任何网络基础，可能你上完14天的课连什么是路由器和交换机都分不清！

现有证据，可以基本断定「定向丢包」

但我得把「断定」和「猜想」分清楚，所以下面分两段说。已经证实的是：同一天、同一台 NAS、同一个端口，来自云服务器的连接完全正常，来自蜂窝手机的连接拿不到回包——而且换成电信卡也一样拿不到。也就是说，处理结果只跟「来源网络是住宅还是机房」有关，跟目的地运营商无关，这是观测到的事实。

还没有证实的是：具体是哪一跳设备丢的、依据什么策略丢的，我在用户侧看不到。可能是骨干网对某个方向的策略丢包，可能是蜂窝网络对终端入站的限制，也可能是某种按源地址段分流的黑白名单式策略——这几种原因的表现会长成同一个样子。我不会挑一种当成定论，因为一旦被证明不对，前面所有真凭实据都会跟着被质疑。

但这恰恰是我要找运营商的原因：上面这几种可能，责任方都是它自己。两端的地址段是它的，路径也在它网内，结论该由它给。我要的也不是「你猜一个原因」，而是让他们自己在骨干网上对同一组五元组做一次双向抓包——包是在哪一跳没有的，一看就知道。

顺便说清一种常见的追问方式：「那你抓个包不就知道谁拦的了吗」。答案是——不能。抓包只能证明包走到哪里为止，证明不了下一跳为什么把它扔掉。丢包的设备不会在包里写批注，中间设备也完全没有义务回你一个「我不转发」的通知。要定位到具体环节，只能由掌握中间设备的一方去抓。这也是为什么这件事必须由运营商来回答，而不是我自己再多测几次。

他们可以不下结论，不代表我不下结论：目前，结合其他社区网友和自己的测试结果可以说的是：联通存在黑白名单！对于VPS、CDN这一类白名单列表不受限，但是一旦换到“公众线（个人手机卡、宽带）”的网络，立马限制。

我的个人猜想就是联通为了限制PCDN故意限制的，PCDN很大程度上依赖于P2P，而限制主动的TCP和UDP连接可以很好的应对这种情况。而联通非常鸡贼，不同于以往的限速5Mbps，它采用的是连接层对数据回包全丢的策略。这种策略测速、上网、玩游戏都没有任何问题，但是一旦涉及到P2P类型的应用就立马原形毕露！PCDN相关社区苦不堪言的SA板卡限速就是如此

说点难听的：为了打击 PCDN，一刀切了所有人

写到这里，我把技术部分讲完了。下面这段是情绪，你可以跳过——但我觉得它比技术部分更接近问题的根子：一个人人都可能用到的功能，为什么会被一刀切掉。

先说我自己的体感。那几通电话打下来，我最强烈的感受不是「他们不专业」，而是——这套流程的设计目标不是解决问题，是让投诉安全地结束。态度全程很好，记录全程规范，然后呢？没有然后。

但这里我得先把一句公道话说在前面：我不怪接线的那个人。媒体调查写得很清楚，一线客服手里没有改套餐、查路由、放行端口的权限，能做的只有道歉、记录、上报；用户的气全撒在他们身上，工单在后台拖着，用户等不及再打一次，还是这一个人挨第二遍骂。所以「客服没用」这件事本身，是被设计出来的，不是某个人不努力。

有个细节我印象特别深。有营业员对记者说过：柜台是有录音的，只有用户自己说出「携号转网」，他才被允许报出折扣价；用户不主动问，他们不能主动说。这五个字比任何脏话都更能说明问题——不是员工不懂，是制度不许。

说到翻旧账，联通的履历不短。2017 年它推出一批便宜到夸张的合作套餐（腾讯王卡、蚂蚁宝卡那一批），但只对新用户开放，老用户想用就得再办一张卡。当时论坛上骂出来的那句「老用户与狗不得办理」，就是这么来的。这事最后是工信部约谈三家运营商，明确要求不得限制用户资费选择权、要为改套餐提供方便。这条是公开记录，不是段子。

再看一个数字。中国消费者协会的数据显示，2024 年全国电信服务投诉量比上年增长了 99.1%，不正当营销是主要投诉内容之一。工信部的口径类似：2025 年第三季度，全国电信用户申诉里涉及营销的占比 10.1%。一年翻倍这个量级，比任何个人吐槽都重。

难看的一面还没完。南方周末的调查里，联通营业厅员工一个月的指标是新办 60 张卡、8 个携号转网、15 条宽带；有位员工因为没完成携号转网被罚了近两千元，而她月均到手不过两三千。

给运营商做外包的第三方外呼公司，业绩不达标要「体罚」——深蹲、跑步、跳绳、转呼啦圈，还得自拍为证。有外呼员说得特别实在：「我真希望用户直接挂。」

把这些拼起来，我的看法是这样的：问题不在某个人的水平，而在这套系统的目标函数里，根本不存在「帮用户把技术问题解决掉」这一项。考核里有的是新增用户、宽带条数、携转量、外呼时长。当一件事不计入考核，它就等于不存在。所以不是「要技术没技术」，而是技术投入再大也不产生绩效，那为什么要投？

这也解释了你感受到的那种「高高在上」。行业增长见顶、利润承压，最省事的做法就是把成本往下压：砍预算、砍人力、砍培训，再把服务包装成指标层层压到柜台。「降本增效」传到末端，往往只剩下「降本」，增效那部分留给用户自己承担。有人管这叫「降本增笑」，我觉得挺准。

但最让我不理解的其实不是成本，是对需求的想象能力。2025 年的中国，光是《中国 IPv6 发展报告》里的数字就足够好看：IPv6 活跃用户 8.65 亿，居世界第一；家庭网关 IPv6 开启率 96.86%。

换句话说，网建得全球最大、光猫基本都开着 IPv6——然后用户连自己家的 NAS 都连不上。一边把 IPv6 当作成绩单来宣传，一边把入站默认全部封死，这等于花钱建了一张只能用来下载的网。

而且这不是我瞎抱怨，行业自己的标准文件就写着。IETF 的运维安全文档里明确提到：只放行出站、阻断一切入站的策略，「打破了 IPv6 的端到端可达性承诺」，并建议家用网关必须给用户一个明确的选择。文档里还举了个落地例子：瑞士电信的做法是默认开放入站，只屏蔽少数已知易受攻击的端口。

对照一下国内的默认值——全封，理由通常是「为了你好」。

再往隔壁看一眼。越南主管通信的部门已经把「IPv6-only」写进了国家路线：2025 年 10 月那份决定规划 2026–2030 年把采用率做到 90–100%，逐步退役 IPv4；家庭宽带在给家用路由器做前缀委派。

按 APNIC 的统计，越南的 IPv6 能力已经到 61.7%，排在全球第十。我不想靠贬低自己来抬高别人，但事实摆在这里：人家在把「每台设备都能被直连」当作目标，国内这边在把它当成风险。

最让人不舒服的其实是那个潜台词——「用户不懂，替他把门锁上更安全。」我家有 NAS、有软路由、有自建服务，我要的是「哪些口开、开给谁、后果我承担」，这是可配置的安全，不是替我关掉。把「用户不懂」当成默认前提，结果是所有懂的人一起被锁在门外，还得自己扛着梯子爬墙。

骂到这儿，我得把话拉回来。上面这些情绪都不构成「我这次连不上自己家 NAS」的证据。证据还是那三行数字：93、134、0。情绪能让人把文章读完，但只有数字能让对方没法绕。所以真去投诉的时候，别学我这一段抒情——直接把抓包甩过去，然后要求他们回答一个问题：包是在哪一跳没有的。

你也可以自己测一遍（最小成本版）

这套测试不需要什么专业设备，也不需要动服务器配置。你需要的只有两样：一台不在你家网络里的观测点，和一次耐心。

1. 准备一台外部观测点。最便宜的是几十块钱一年的云服务器，自带公网 IPv6 就行。没有的话，让朋友在他家网里帮你跑命令也可以，前提是别和你同一个运营商。
2. 确认目标地址。一定要去设备后台看当前有效的那一个，别用之前记下来的——前缀会变。
3. 在你自己这边的出口抓包，按时间跑，别设包数上限。
4. 同一时间只换来源：先让云服务器连一次，再让手机流量连一次。别的什么都别改。
5. 数三个数：对端发了几个 SYN、你回了几个 SYN-ACK、对端回了几个 ACK。第三个数如果是 0，你手上就有结论了。

如果懒得开终端，还有个更省事的观察角度：看官方投诉页面的判断，再对比同一地址从云服务器访问是否正常。两个结果不一致，就说明问题不在你的设备上。

唯一要注意的是：别在同一条线路内部测自己。你在家里 ping 自己家的地址，走的是局域网，必然成功，这个结果没有任何意义。

还有个小习惯值得养成：测的时候把「几点几分做的、从哪个网络做的」记下来。因为一旦你要找对方对时间轴，对方第一句一定是「你什么时候测的」。你手里有时间点、有地址、有抓包文件，对面的技术才有可能在自己的设备上翻到那一段流量；没有时间点，对话就只能停在原地。

写这一节不是为了显得我专业。纯粹是因为我太清楚那种感觉了：一个人对着客服讲技术，对面在念话术。

顺便说：这也解释了厂商的「远程访问」为什么修不好

我折腾这件事的起点，其实是想用手机访问家里的 NAS。厂商的 App 一直显示「转发模式」，也就是走它自己的服务器中转，慢且不稳定。

查到最后我发现：这类 P2P 直连的本质就是「客户端主动连你家」。回程依然是「家宽 → 移动网络」这个方向——跟上面被丢掉的包是同一条路。所以就算厂商那边把 P2P 修好，手机大概率还是连不上；中继反而成了唯一能用的通路。

这个判断有点反直觉：「直连」不一定比「中转」好。在正常的网络里直连确实更快，但在回程被丢的情况下，那条看起来笨拙的中转路径反而更可靠——因为它的两端都是「客户端主动连服务器」，方向上天然不受影响。

如果你也在折腾家里的远程访问，可以看看我之前那篇《人在外面，怎么进家里的网？》——用云服务器做中转的思路，在这个场景下恰好就是对症的那一版。

我现在打算怎么办

• 先拿证据去投诉，按上面那套话术走，把抓包文件一起交上去；
• 换一张别的运营商的卡做对照——这一条已经做完了：电信卡和联通卡表现完全一致，两张卡的 ACK 都是 0，「换卡」这条路正式排除。剩下的变量只有一个——发起方是住宅源还是机房源，而这一条只能由运营商在骨干网上抓包才能定论；
• 绕过方案先上：既然「家宽 ↔ 数据中心」和「手机 ↔ 数据中心」两个方向都正常，那就在云服务器上做中转，把家里的服务经它转出来。不优雅，但今天就能用。

说实话，「先绕过」这个选择让我不太舒服——绕过等于默认了这件事就这么算了。但现实是：联通给不出结论之前，我总得先用上自己家的设备。所以我的做法是两条腿走：一边把中转方案跑起来保证能用，一边继续把工单往上推。

顺便说个取舍：经数据中心中转会把你的流量完整经过一台第三方服务器，所以要么用自己可控的机器，要么就接受「服务商能看到你的流量」这件事。别随便找个免费中转，那才是真的把家门钥匙交出去。

最后

如果你也遇到过「IPv6 打不通」，我的建议是别再跟客服拼口头解释了，先把方向测出来：找一个不在你家网络里的观测点，在同一时间、对同一目标、只换来源，抓一次包。

一进一出两个方向的数字摆在一起，剩下的就不需要吵了。

有一件事我想写在最后：我并不是要证明「联通故意针对我」。可能是某个方向的路由配置出了问题，可能是某次策略变更的副作用，也可能是我完全没想到的第三种原因。我要的只是一个能被证实的解释，而不是一句用来结束通话的话。

所有的抓包文件、分析记录和复现脚本，我都整理成了一个证据包，任何人都可以点开下载、自己用 Wireshark 核对——里面每一个数字都能逐条对上，我没有藏任何东西。为了让它可以公开分享，pcap 里的真实地址做了脱敏（包的数量、方向、时序、协议一点没变），未脱敏的原始文件另外放在一个单独目录，只用于提交给运营商定位。

证据包下载：

• 下载地址：https://ug.link/xiaozou/filemgr/share-download/?id=b80091cfba7e46749ee2c5c85f4dd5c4
• 访问密码：UxHC
• 内容：两个抓包文件（.pcap，附脱敏版与原始版）、8 份分析记录、18 个复现脚本、以及一份写给非技术读者的说明（index.html，浏览器直接打开就能看懂结论）

如果你下载打开后有任何疑问，或者你自己跑出了不一样的结果，欢迎留言——我把原始数据都摆在这儿，就是想让这件事可以被验证，而不是只能听一面之词。

有进展我会补一篇后续。毕竟到现在为止，我这边唯一确定的事，是那些包确实出了我家门。