联通「家宽没有这个功能」：NAT4 与 IPv6 回程丢包实测

10015 回电了。通话不到5分钟，内容基本上就两句：家庭宽带没有这个功能，办不到；有需求可以办企业宽带。没有书面说明，没有技术依据，没有工单编号，连「我们内部评估过」这种话都没有。我要求他们出一份专业的答复，等来的是这句话重复三遍。那就把整条链路重新摊开一次。这次不靠嘴说，只放数字：入了几个包、出了几个包、对方收到几个包。三个数摆在一起，剩下的不需要争。狠狠的抽运营商的脸，让他们出面再解释。

一、事情是怎么走到这一步的

时间	发生的事
今年 6 月	办理广东联通家庭宽带，装维上门，光猫改桥接，PPPoE 由自己的软路由拨号（iStoreOS）
8 月	IPv6 入站突然不通，之前能用的服务全部失联；NAT 类型测出来是对称型（NAT4）
8 月中	找装维，装维说这块不熟；找客服，客服反复说「你需要公网 IP」
8 月下旬	向工信部渠道提交申诉，工单被派回本地，来电话的还是普通客服
10 月	转 10015，提出三条诉求，对方承诺 48 小时内回复
现在	10015 回复：家宽没有这个功能，建议办企业宽带

技术取证的完整过程在上一篇《联通 IPv6 打不通，客服只会说「你家没有公网 IP」》里，pcap 和复现脚本都放出下载了。同一系列的另外几篇：广东联通宽带实测：华为 BRAS、对称型 NAT4、客服态度不错但问题还在、开启 PCP-NAT 的尝试，设备侧能不能配全锥、能不能做端口映射，用 NE8000 拆过「设备不支持」这句说辞。

这一篇只回答一个问题：他们说「没有这个功能」，指的是哪个功能。

二、先把现象测清楚，别给对面留退路

投诉最怕的不是对方不认，是你自己测错了。所以这次把变量掐死：光猫桥接，软路由自己 PPPoE 拨号，IPv6 forward 链放行指定端口，服务监听在 NAS 的 9443，抓包点固定在家宽出口 pppoe-wan。

更关键的是抓包方法。第一版我犯了两个错：一次先测外网、再测手机，两份结果对比——时间、源端口、路径全都不同，对方一句「你这两次条件不一样」就能把结论顶回来；另一次抓包脚本设了抓满 600 个包就退出，结果背景扫描流量三十秒占满名额，真正的测试在几分钟后才开始，那一轮数据全废。

改成：同一个抓包点、同一台机器、同一个端口，唯一变量是来源网络，两组数据落在同一份抓包里。 手机上点两次，一次用联通卡，一次用电信卡，中间不关抓包。

# 按时长跑，不要设包数上限（这是我栽过的坑）
tcpdump -i any -n -s 0 -w /tmp/cap.pcap 'ip6 and tcp and host PEER_IPv6'

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

结果是这样：

计数项	A 路 · 腾讯云（机房源）	B 路 · 联通蜂窝手机
入向 SYN（对端发出，含重传）	8	93
出向 SYN+ACK（我家应答）	8	134
入向 ACK（对端确认收到应答）	26	0
出向 PSH（数据）	21	0

A 路那 26 个 ACK 说明对端确实收到了我家的应答；B 路那个 0 说明手机一个都没收到。而抓包显示得更细：手机的 SYN 进了我家 pppoe-wan、被转发到 br-lan、送到了 NAS 的网口，NAS 回了 SYN+ACK，回包也真的从我家出口发出去了。然后就停在那儿——手机那头翻来覆去重传同一个 SYN，因为在它看来对面从来没答应过。

这里顺手纠正一个到处被写错的细节。TCP 三次握手是 SYN → SYN+ACK → ACK，第二步回的是 SYN+ACK，不是单独的 ACK。真正的观测是：被动方回了 SYN+ACK，主动方没收到。

TCP 三次握手对比：云服务器连接走完 SYN、SYN+ACK、ACK 三步后正常传输；联通蜂窝手机发出 93 个 SYN，家里回 134 个 SYN+ACK，最后一个 ACK 从未出现

三、换成 UDP 和 ICMPv6 再测，结论一个字没变

上面这些数据有个共同的漏洞，得自己先点出来：全是 TCP。 如果对方只对 TCP 做了手脚，那个「入站被拦」的结论就下早了。

所以换 UDP 重测。选它是有理由的：UDP 连握手都没有，失败是完全无声的，没有 RST、没有拒绝，只能两边同时抓包看包死在哪。老规矩，唯一变量是协议，同一台 NAS、同一个出口抓包点、同一个方向。

# 家宽出口抓到的 UDP（节选）
21:05:51.547  In  手机.34587 > NAS.9878  UDP, length 20   <- 请求到达
21:05:51.548  Out NAS.9878 > 手机.34587  UDP, length 68   <- 家里立刻回了
...
21:06:37.531  In  手机.37670 > NAS.9878  UDP, length 20
21:06:37.532  Out NAS.9878 > 手机.37670  UDP, length 68

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

17 个请求全部到达，家里逐条回了 17 个应答，手机收到 0 个。回包校验和错误 0 个，把「回包是坏包」这条也排掉。

再把第三个协议也试了：ICMPv6，也就是 ping，方向从我家往手机打——5 个包，0 个回应。同一个方向，同一件事。

这一步的分量在哪：TCP 要三次握手，UDP 连握手都没有，两套机制几乎找不到共同点，表现在同一个方向上却逐条一致。所以结论不能写成「TCP 被限制」，只能写成：不是某个协议被拦，是这个方向上的回包在丢。 这不是为了显得严谨——恰恰是这句话把结论钉得更死，对方再想说「我们没封 TCP」，连提都提不出来。

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

四、机房源全通、蜂窝源全堵：这是黑白名单！

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

发起方	对 NAS:9443 的实测结果
腾讯云（机房源）	ICMP 5/5，0% 丢包；TCP 9999 / 9443 / 80 / 443 全部 OPEN；HTTPS 返回 HTTP 307，首字节 23ms；下载跑满 115 Mbps
联通蜂窝手机	93 个 SYN 到达、134 个 SYN+ACK 发出、0 个 ACK 回来
电信蜂窝手机	9 个 SYN 到达、11 个 SYN+ACK 发出、0 个 ACK 回来
两张卡合计（同一次抓包）	26 进、40 出、0 回

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

把变量再删干净一点。换一张电信卡插进同一台手机，结果一模一样，所以「手机是联通的所以被联通内部限制」不成立；两端地址都是联通自己发的，所以「跨运营商互联互通」这个借口也用不上：

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

前两段同属 2408:8000::/20，一个注册记录。从我家门口到手机，全程都在联通自己的网里。第三行是补的对照：换成完全另一家运营商的卡，结果一样，所以「换一家试试」这条退路也堵死了。

三个变量——目的运营商、手机设备、服务端——全部排掉，只剩一个：发起方是住宅源还是机房源。 结合自己和社区网友的测试，最合理的解释只有一种：存在黑白名单。VPS、CDN 这类白名单线路不受限，一旦换到「公众线」（个人手机卡、家庭宽带）就立刻限制。

但「哪一跳设备丢的、依据什么策略丢的」，我在用户侧看不到。可能是骨干网对某个方向的策略丢包，可能是蜂窝侧对终端入站的限制，也可能是按源地址段分流的策略——这几种表现会长成同一个样子。这正是找运营商的原因：两端的地址段是它的，路径也在它网内，结论该由它给。 我要的不是让他们猜一个原因，而是要他们在骨干网上对同一组五元组做一次双向抓包——包是在哪一跳没有的，一看就知道。

顺便把一种常见的追问说清楚：「你自己抓个包不就查出谁拦的了？」不能。抓包只能证明包走到哪里为止，证明不了下一跳为什么把它扔掉。丢包的设备不会在包里写批注，中间设备也没有义务回你一个「我不转发」的通知。这件事只能由掌握中间设备的一方来回答。

五、「没有这个功能」这句话错在哪

IPv6 没有 NAT，这是设计前提，不是可选项。运营商给你一段 /64 前缀，里面每个地址都是全球可路由的。这个需要要我证明，因为只要你能上网，这条路就是通的，因为上网的数据传输是双向的。你要一份数据，你也得告诉服务器收到数据了，服务器才会发下一份数据，这个就是TCP协议的特性；一个包能不能到你的设备，只看路径上有没有人主动把它掐掉，而不是看运营商开没开某个「功能」。

所以「家庭宽带没有这个功能」翻译过来是「我们把它关了」。能力和策略是两件完全不同的事，混在一起说就成了完美的挡箭牌。设备侧那句「不支持全锥型 NAT」是同一个套路：把「我们不给你配」说成「设备做不到」，用户一听就无从反驳。运营商典型做法，不想动就把责任往外推！

三条反证，任何一条成立，这句话就站不住：

同一台 NAS、同一套防火墙规则，换一张电信卡照样连不上，换机房源却连得通。 能力在终端侧完全具备，缺的那一环在运营商网络里。
我家那个 IPv6 地址是联通通过 PPPoE 下发的，不是 fd00::/8，也不是 fe80::。我从外部云服务器直接连进了这个地址，握手成功、拿到真实响应、下载跑满 115 Mbps。如果「没有公网 IP」，这件事不可能发生。
手机发来的 93 个 SYN 全部到达我家入口。入站是通的，这跟「没有这个功能」自相矛盾，因为路由是可达的。

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

对照一下国内的默认值——全封，理由通常是「为了你好」。这个逻辑最难受的地方在于它的潜台词：「用户不懂，替他把门锁上更安全。」 我家有 NAS、有软路由、有自建服务，我要的是「哪些口开、开给谁、后果我承担」，这是可配置的安全，不是替我关掉。把「用户不懂」当默认前提，结果是所有懂的人一起被锁在门外，还得自己扛着梯子爬墙。

而这件事跟国家自己的方向是反的。《深入推进 IPv6 规模部署和应用 2024 年工作安排》要求到 2024 年末固定网络 IPv6 流量占比达到 23%，「IPv6 网络性能显著提高，使用体验提升明显」（gov.cn 原文）。《中国 IPv6 发展报告》的数字更好看：IPv6 活跃用户 8.65 亿，居世界第一，家庭网关 IPv6 开启率 96.86%。

换句话说，网建得全球最大、光猫基本都开着 IPv6——然后用户连自己家的 NAS 都连不上。花钱建了一张只能用来下载的网。运营商这样做不叫推进IPv6互联网建设，而是把IPv6掐死在摇篮里！

再往隔壁看一眼。越南主管通信的部门已经把「IPv6-only」写进国家路线：2025 年 10 月那份决定规划 2026–2030 年把采用率做到 90–100%，逐步退役 IPv4；家庭宽带在做前缀委派。按 APNIC 统计，越南的 IPv6 能力已经到 61.7%，全球第十。人家把「每台设备都能被直连」当目标，我们这边把它当风险。国家大力推行的IPv6，其最大的动力就是每个设备一个公网，去NAT话，而运营商正在把这个动力砍掉，只剩下一个政治任务！

六、网上那些说法，哪些能对上，哪些对不上

这事不是我一个人遇到的。翻了V2EX 那个 60 多楼的帖子，把能验证的和不能验证的分开列。

对得上的：

有人一句话点破：「你查一下肯定是 nat4」。我这边测出来确实是对称型，NAT4 和 IPv6 入站封锁同时发生，不是巧合。
有人提到佛山联通 2023 年 8 月就开始回收公网 IPv4。时间线和这次收紧对得上，不是临时故障，是持续收口。
最关键的一条：那位楼主测出「本市无法访问，外市可以，境外 VPS 也可以」。我这边现象一致。这条把光猫防火墙、MTU、路由配置全部排除——那些问题不会长眼睛只拦同城流量。
还有人提到投诉到工信部只收到一条「不行」的短信。我的经历一模一样，只不过我收到的是电话。

对不上的：

有人说广州联通高位端口（8443 之类）能通、只封 80/443。我这个市的观测不支持这个结论：9443 是高位端口，照样不通，而且是回包不通，不是端口被封。各市策略不一样这件事本身就是问题——同一家运营商、同一个省，用户拿到的网络能力取决于住在哪个市。
有人坚持「肯定是光猫防火墙」。我的光猫是桥接的，拨号在软路由，IPv6 规则自己写，这条不成立。但我不否认这是绝大多数人踩坑的第一现场，排查顺序上先排除它没毛病。

那个帖子里最扎人的不是技术讨论，是这句：投诉也没用，返回一条短信就是不行。当所有申诉渠道的终点都是同一句话，用户会自己去解释原因——而用户编出来的解释通常比真相更难看。

七、企业宽带那张价目表，我看了两遍

10015 让我去办企业宽带。那就看看企业宽带卖的是什么：在售套餐 100Mbps 下行、10Mbps 上行，400 元一个月，公网 IP 还得另说。4800 一年。

这里面最贵的不是带宽，是上行。10Mbps 换算成 1.25MB/s，挂个照片备份都要排队。国外主流固宽在这一档价位上通常给到对等或者至少几百兆上行，价格量级差不多还更低。我不想拿某一家资费单当证据，这玩意儿随时变，但「下行百兆、上行十兆、四百块一个月」在 2026 年确实不像一个正常市场的报价。这是不是长期垄断带来的结果，我深表怀疑！

更微妙的是产品设计：把本该是协议默认行为的东西，切出来单独卖。 IPv6 入站、端口映射、非对称 NAT，这三样不是增值服务，是协议栈的默认能力。先把默认能力关掉，再把「打开」包装成企业级功能溢价出售——这条路走下去，下一步是不是要给 ping 也开个套餐？是不是后来上行只给5Mbps，然后多余的要额外交钱？

网络质量不是单看下行。整个链路是木桶，最短那块板决定体验：上行、延迟、丢包、NAT 类型、入站可达性，任何一项塌了，千兆下行也只是看着舒服。

丢包这一项还能翻旧账。之前有玩家发现，把测速网站的 HTTP 特征伪装一下，卡顿立马消失、带宽也回来了。原因是运营商侧对不在白名单里的流量做了丢包处理，而 TCP 的拥塞控制（CUBIC）一检测到丢包就主动降速。这条属于社区观察，我没做独立复现，但它能解释为什么「测速很快、用起来很慢」会同时成立——测的是白名单通道，用的是被整形过的通道。

八、为了打击 PCDN，一刀切了所有人

每次聊到上行和入站，总有人把 PCDN 拎出来：「你这么搞会助长 PCDN，运营商当然要管。」听着有理，其实是把责任错位了。

我的判断是：联通为了限制 PCDN，故意限制主动发起的 TCP 和 UDP 连接，因为 PCDN 很大程度上依赖 P2P。而且手法很不体面——不是以往那种明面上的限速 5Mbps，而是在连接层把数据回包全丢。这种策略测速、上网、玩游戏都毫无异常，一旦涉及 P2P 类应用立刻原形毕露。PCDN 社区苦不堪言的 SA 板卡限速，走的就是这个路子。

但这套逻辑本身站不住：

运营商没有执法权。如果认定 PCDN 违规，路径是推动立法、约束上游厂商和平台，而不是在接入侧对所有家宽用户做无差别降级。惩罚一万个正常用户去堵一个违规用途，这叫懒。
PCDN 为什么存在？因为商业带宽太贵。视频平台算不过来账，才会去用不稳定的家宽做分发。定价合理，这个灰色市场自己就萎缩了。
把回程回包丢掉、把 NAT 压成对称型，结果是每个家庭都变成孤岛，所有流量被迫挤到中转服务器上。中转带宽被摊薄，服务质量年下降——这是你们想要的发展路线？
宣传口径永远只提下行峰值。丢包率、NAT 类型、上行带宽、入站可达性，这些真正决定体验的参数，从来不出现在海报上，也不写进合同。

还有一个连带后果，值得单独说：厂商 NAS 的「远程访问」修不好，跟这是同一件事。这类 P2P 直连的本质是「客户端主动连你家」，回程走的还是「家宽 → 移动网络」这条被丢的路。所以就算厂家把 P2P 修好，手机大概率还是连不上——中继反而成了唯一能用的通路。 反直觉，但在回包被丢的前提下，「直连比中转快」这个常识不成立。

九、别把火撒到装维和客服身上

这事的执行环节在一线，但决策不在。装维数通不熟，客服只会背话术，不是他们不想解决，是培训体系里就没教这些。

这点我有资格说，因为我在联通实习过。培训是外包公司（中通文博）做的，总共 14 天：12 天讲营销，1 天讲技术，最后一天考试。完全不碰计算机网络——如果你没有任何基础，上完 14 天可能连路由器和交换机的区别都分不清。

而且这类岗位大量外包，福利和正式员工两套体系。夏天顶着太阳爬楼装机、扫楼推卡，出了投诉还是他们去面对。我朋友在一线，工资条是这样：

联通一线装维工资条：底薪 3500 元，业绩不达标扣 1000 元，实发 2500 元

底薪 3500，业绩不达标扣 1000，一个月到手 2500。让拿这个工资、没受过专业培训的人去回答「为什么 IPv6 回包被丢」，本身就不合理。该回答这个问题的是网络部门，不是营业厅。

更值得看的是这套系统的目标函数。南方周末的调查里，营业厅员工一个月指标是新办 60 张卡、8 个携号转网、15 条宽带；有员工因没完成携转被罚近两千，而她月均到手不过两三千。中消协的数据显示，2024 年全国电信服务投诉量比上年增长 99.1%；工信部口径类似，2025 年第三季度申诉里涉及营销的占 10.1%。2017 年那批只对新用户开放的便宜套餐，逼出了「老用户与狗不得办理」这句话，最后是工信部约谈三家运营商才收场。

把这些拼起来，结论很清楚：问题不在某个人的水平，而在考核里根本没有「帮用户把技术问题解决掉」这一项。 新增用户、宽带条数、携转量、外呼时长都有指标，技术投入再大也不产生绩效，那为什么要投？「降本增效」传到末端，往往只剩「降本」，增效那部分留给用户自己承担。

十、想自己验证的话，按这个顺序来

不管你是想投诉，还是只想搞清楚自家宽带被做了什么，这套测试不需要专业设备，只要两样：一台不在你家网络里的观测点，和一次耐心。 前提是家里光猫桥接、路由自己拨号，否则你测的是光猫不是运营商。网上很多网站就能直接测试宽带的IPv6可达性，比如：IPV6版_在线tcping_tcp延迟测试_持续ping_禁ping_tcping_端口延迟测试。为了验证我的说法，我拿我自己的NAS给大伙测试一下

看到没，一片全红，这就是你联通干的好事！动手前先用站内两个工具打底：家庭宽带 IPv4/IPv6 公网 IP 检测确认手上的地址是不是真的全局可达，CGNAT 会话数在线测试看自己被塞进了几层 NAT。两项结果都截图留档，投诉时比口述有用。

准备外部观测点。 几十块一年的云服务器，自带公网 IPv6 就够；没有的话，让不在同一运营商的朋友帮你跑命令也行。
确认目标地址是当前有效的那个。 去设备后台看，别用之前记下来的——家用 IPv6 前缀会跟着 PPPoE 重拨变化，旧地址还挂在网卡上但已经不通了，拿失效地址去测，结果就是 100% 丢包，看起来跟「被封了」一模一样。
在自家出口抓包，按时长跑，别设包数上限。
同一时间只换来源。 先让云服务器连一次，再让手机流量连一次，别的什么都别改。
数三个数：对端发了几个 SYN、你回了几个 SYN+ACK、对端回了几个 ACK。第三个数如果是 0，你手上就有结论了。
换协议复测。 UDP、ICMPv6 各来一遍，排除「只针对 TCP」的可能。

# 1. NAT 映射行为（需要一台有公网 IPv4 的机器跑 STUN）
pystun3

# 2. IPv6 回程对照：外部 VPS 监听，家里主动连出去，看回程能不能回来
ncat -6 -l 8080                      # VPS 侧
printf 'hello' | ncat -6 -v VPS_IPv6 8080   # 家宽侧

# 3. 家宽出口抓 SYN / SYN+ACK，看谁到了、谁没到
tcpdump -i any -n -s 0 -w /tmp/cap.pcap 'ip6 and tcp and host PEER_IPv6'
tcpdump -enr /tmp/cap.pcap           # -e 打印接口与方向，判断包死在哪一跳

# 4. 换协议对照，区分「只丢 TCP」和「整个方向都在丢」
ping6 -c 5 PEER_IPv6

唯一要避开的坑：别在同一条线路内部测自己。 你在家里 ping 自己家的地址，走的是局域网，必然成功，这个结果没有任何意义。还有个小习惯值得养成——把「几点几分、从哪个网络做的」记下来。因为一旦要找对方对时间轴，对方第一句一定问「你什么时候测的」，没有时间点，对话就停在原地。