在上篇文章 基于原生 IPv6 与 NPM 实现 Win11 本地服务低延迟公网暴露 中，我们讨论了在主路由器能够进行 PPPoE 拨号的理想环境下部署 HomeLab 的全流程。然而在现实的复杂网络中，很多朋友（包括我自己）常会遇到更为棘手的客观限制——没有光猫的超级管理员密码，光猫保持默认路由模式，而自己折腾的路由器（如刷了老毛子 Padavan 固件的斐讯 K2 ）只能充当二级路由。
本文并不是一次 IPv6 配置失败后的修复，而是在已经实现公网 IPv6 获取和 Tailscale P2P 直连之后，对家庭网络结构进行重新优化的一次排查记录。
在江西移动宽带 + 老毛子 K2 二级路由环境下，我先是成功拿到了原生公网 IPv6 出口，并实现了 Tailscale P2P 直连——然而长期使用下来，稳定性和公网入站能力却始终不尽如人意：ddns-go 一直能拿到 IPv6 地址，却无法与 api.cloudflare.com 正常通信、域名记录迟迟更新不了；Tailscale 打洞时好时坏，失败时流量被迫退回位于海外的高延迟 DERP 中转节点（如 sfo 旧金山，延迟高达 400~500ms）。本文将完整还原这段“成功后继续踩坑、最终重构家庭网络结构”的排查全过程。
背景与诉求：没有光猫超级管理员密码，光猫保持默认路由模式。在不修改光猫模式的前提下，让挂载在老毛子 K2 下的 Windows 11 主机获得可用的公网 IPv6，并保证远程访问的长期稳定。
排查时间线总览
先给出本次排查的完整时间线，方便读者把握全文脉络：
1 | 尝试二级路由方案 |
这不是一条“失败 → 修复”的路径，而是一条“跑通 → 发现问题 → 认知升级 → 架构降维”的路径。下文按五个阶段依次展开。
第一阶段：二级路由 IPv6 实验
初始方案
初始方案下，老毛子 K2 作为 IPv6 二级路由。
在重构之前，我的网络采用二级路由方案，拓扑与流量走向如下：
1 | 江西移动光猫 |
这个初始方案的目标有三个：
- 获取公网 IPv6 地址
- 支持 Tailscale IPv6 打洞
- 尝试公网访问家庭服务
第一阶段的具体排查路线：
1 | 升级老毛子固件 ──► 开启 Stateless Native ──► 放行防火墙 ──► 排查 Windows 网卡与更换 DNS ──► 成功获取公网 IPv6 ──► Tailscale P2P 直连 |
斐讯 K2 设备说明
刷机之前，先确认手里的硬件版本。斐讯 K2 的平台代号是 PSG1218，市面上存在两个内存版本：
- 64M 内存版本
- 256M 内存版本
固件兼容性需要与具体硬件版本核对，刷错固件轻则功能缺失、重则变砖。此外，长期运行 Padavan、插件和各种网络服务时，内存差异会直接影响稳定性表现，选购和刷机时需要格外注意。
刷固件与后台 IPv6 配置
说明：以下配置记录的是排查过程中的实验方案，并非最终的家庭网络结构。这一阶段的目标是验证老毛子作为二级路由时能否传递公网 IPv6。
首先将老毛子 Padavan 固件更新至较新版本（替换掉了 2017 年的遗留老固件）。
前往老毛子Padavan固件的下载地址：Padavan，找到斐讯K2路由器可以使用的最新固件版本进行更新
进入老毛子后台（192.168.123.1），在 高级设置 → 外部网络 (WAN) → IPv6 设置中做如下调整：
- IPv6 服务连接类型：选择 Stateless Native / DHCPv6 模式。
- 关闭路由内置的一系列 IPv6 防火墙阻拦规则。
- 关闭 NAPT66 服务、IPv6广播中继服务。
左边是第一次尝试的路由配置，右边是第二次尝试的路由配置（均为二级路由实验阶段截图）。
相比之下，第二次配置将路由器 WAN/LAN 的 DNS 均指引至阿里云公共 DNS（2400:3200:baba::1 和 2400:3200::1），并将 启用 LAN DHCPv6 服务器 切换为 Stateless 模式，成功让下级设备打通了 IPv6。
结果是：第一次的路由配置无法正常使用 IPv6 进行上网，第二次的路由配置可以获得公网的 IPv6。
这里还踩过一个典型的坑：曾尝试开启 NAPT66，结果它把公网 IPv6 强行转换成了内网私有 IPv6。IPv6 的本质是端到端直连，开启 NAPT66 属于典型的“画蛇添足”。（在最终 AP 模式下，K2 不再承担 IPv6 出口职责，因此 NAPT66、防火墙转发等功能也不再成为关键因素。）
Windows 网卡排查
在完成路由器设置后，Windows 依然打不通 curl.exe -6 https://api64.ipify.org。在 PowerShell 中运行以下诊断命令查看网卡状态：
1 | Get-NetIPInterface -AddressFamily IPv6 |
终端回显结果如下：
再使用 ipconfig 查看网卡的具体配置：
1 | ipconfig |
延伸阅读：本文主要针对 IPv6 与 Tailscale 相关的特定诊断命令进行排查。如果你需要更全面地排查 Windows / Linux 环境下的网卡路由、DNS 污染及端口连通性，可以参考单独整理的：家庭服务器网络诊断命令清单 。
解决旧 DNS 缓存与地址超时
即使改了路由器 DNS，如果 Windows 本地网卡先前手动指定过 IPv6 DNS，依然会因为配置冲突或保留无效 DNS 而导致域名 AAAA 解析全部超时。在 PowerShell 中测试解析：
1 | nslookup -type=AAAA api64.ipify.org |
终端输出超时异常：
排查时发现，我此前的确在 Windows 网卡属性中手动指定过固定 DNS 地址，与老毛子路由器通过 RA/DHCPv6 下发给网卡的 DNS 发生了冲突。将 Windows 本地的 IPv6 DNS 修改为 DHCP 自动获取：
并清理缓存：
1 | ipconfig /flushdns |
确认 Windows 改为自动获取并生效后，执行公网路由追踪命令：
1 | tracert -6 2606:4700:4700::1111 |
发现打通外网，终端回显完整的跳跃路径：
验证 IPv6 出站
1 | curl.exe -6 https://api64.ipify.org |
可以正常返回公网 IPv6 地址，说明设备具备公网 IPv6 出口：
Tailscale P2P 验证成功
实验初期运行 tailscale netcheck 时一直提示 IPv6: no, but OS has support——网卡拿到了地址，却无法真正连接外网 IPv6。修复之后，用以下命令做验证：
1 | tailscale netcheck |
tailscale netcheck 的输出里，IPv6: no 终于变成了 IPv6: yes：
再用手机（切换为中国电信 5G 移动网络，关闭 Wi-Fi）做打洞测试，成功实现了电信 5G ↔ 移动宽带下的 原生 IPv6 端到端 P2P 直连，摆脱了原本高达 400~500ms 的美国 sfo DERP 转发节点 [注1]：
以上流程打通了 IPv6 出站与 P2P 直连——但正如时间线所示，这只是故事的上半场：长期使用中打洞频繁失败，稳定性存疑。接下来是成功之后暴露的问题。
第二阶段：成功之后暴露的问题
第一阶段的方案，全部推倒重来！
实验阶段的成果并不是一劳永逸的。IPv6 基本功能已经实现，但长期测试发现，不同访问场景的表现各不相同——把连通性拆成三个层级来看，结论完全不同：
- 第一层，IPv6 出站：成功（第一阶段已验证）；
- 第二层，Tailscale P2P：能建立直连，但长期打洞不稳定；
- 第三层，IPv6 原生入站：失败。
下面分别记录这些问题。
IPv6 原生入站失败
用手机 5G 流量直接访问 http://[IPv6 地址]:指定端口，发现无法访问家庭服务。
获取公网 IPv6 地址，并不等于拥有完整的 IPv6 入站能力。
DDNS 更新与打洞不稳定
- ddns-go：一直能获取到 IPv6 地址，但无法与
api.cloudflare.com正常通信，域名记录更新失败； - Tailscale：打洞反复失败，流量退回高延迟的
sfoDERP 中转节点。
双前缀异常
在 Windows 排查阶段还记录到一个当时无法解释的现象：WLAN 无线网卡处于 Connected 激活状态，而在第一阶段的实验记录中曾经出现过两个不同的 IPv6 前缀：
1 | 2409:8a38:8430:xxxx |
但在当时的测试阶段，我并没有意识到这两个前缀分别对应什么网络环境，也无法确定具体来源，只能先列出几个猜想：
- 是否运营商为家庭宽带分配了多个前缀？
- 是否多网卡同时接入（WLAN 与以太网）导致？
- 是否老毛子路由器产生了新的 IPv6 网络？
当时的处理方式：重新断开并重新连接主上网网卡，清理旧的前缀绑定，确保网络出口路径单一清晰。但这只是暂时缓解，并没有真正回答“第二个前缀从哪来”的问题——谜底直到后文才被意外揭开。
第三阶段：发现 IPv6 真实拓扑
意外发现
双前缀的谜底，在一次偶然操作中被揭开。
后续某次测试中，我无意连接到了江西移动光猫自带的 WiFi（SSID 类似 CMCC-xxxx）。查看 IPv6 地址后，发现它使用的前缀与之前老毛子网络环境下记录的 IPv6 并不一致：
1 | 光猫 WiFi 下：2409:8a38:8430:xxxx |
回头重新整理之前的测试记录，才逐渐确认：之前出现的两个 IPv6 前缀，很可能分别对应光猫 WiFi 与老毛子 WiFi 这两套 IPv6 网络环境——两个网络出口各自产生了一套前缀，地址分配路径完全不同。
这也解释了长期使用中“时通时不通”的不稳定现象：终端同时连接两个网络时，可能拿到两套前缀，路由选择变得不可预测。
第四阶段：降低架构复杂度
选择 AP 模式
在理清双前缀的来源、重新理解家庭 IPv6 结构后，我决定不再继续优化二级 IPv6 路由，而是把老毛子 K2 转为 AP 模式：
切换到 AP 模式后，需要先为老毛子设置一个固定的内网 IP——否则地址由光猫动态分配，后台管理入口随时可能漂移。
需要注意的是：如果老毛子的 NAT、防火墙、UPnP、DHCP 服务你是必须需要使用的话，不建议更改为 AP 模式。
之所以选择 AP 模式，不是因为这些：
- K2 性能不足
- Padavan 固件不好
而是因为当前环境下存在太多不可控变量：
- 光猫无法获取超级管理员权限，内部配置完全是黑盒
- 无法确认移动光猫的 IPv6 防火墙策略
- 老毛子二级路由的 IPv6 防火墙状态不透明
- IPv6 链路存在多个控制节点（光猫、老毛子各管一段）
在这样的前提下继续调参，等于在多个黑盒之上做调试。而 AP 模式可以一次性地：
- 减少 RA 广播来源（链路中只剩光猫一个）
- 消除 IPv6 默认路由竞争
- 减少 IPv6 防火墙节点（链路中只剩光猫一个控制点）
- 降低地址分配复杂度（IPv6 前缀只有一个来源）
所以，AP 模式的意义不是“解决 IPv6”——IPv6 出站与 P2P 打洞在实验阶段早就通了——而是降低 IPv6 架构复杂度。在无法控制运营商光猫配置时，减少 IPv6 中间节点比继续复杂调参更加可靠。
光猫负责 IPv6，K2 转为 AP 模式
经过这一轮排查与架构降维，最终的网络结构为：
1 | 江西移动光猫 |
一个现象：Windows 保留旧 IPv6 地址
在调整为 AP 模式、确认链路中只剩光猫一个 IPv6 出口后，继续测试 IPv6 状态时又发现了一个新现象：电脑长时间不关机、持续连接老毛子 K2 的 WiFi，第二天查看 ipconfig 时，发现存在两个 IPv6 地址。
现象：
- 其中一个 IPv6 地址无法进行公网访问；
- 它不是临时 IPv6 地址（RFC 4941 隐私扩展地址）；
- 看起来像前一天网络环境留下的旧地址。
进一步测试：
- 切换连接江西移动光猫自带 WiFi（
CMCC-xxxx），查看 IPv6：只剩一个 IPv6 地址。 - 再重新连接老毛子 K2 WiFi：IPv6 地址恢复正常，只剩一个当前网络使用的 IPv6 地址。
由此推测：
该现象更可能是 Windows 在网络切换过程中保留了旧 IPv6 地址，而不是当前网络同时存在两个 IPv6 出口。
从机制上看，IPv6 地址不一定会随网络切换立即消失：地址存在生命周期，系统可能暂时保留旧地址——旧地址虽然仍显示在网卡信息中，但已经无法作为有效的公网地址使用。
至于这与第二阶段记录的"双前缀异常"是否同源，目前无法下结论：当时观测到的两个前缀，在第三阶段被推断为光猫与老毛子两套网络环境各自产生；但当时的测试记录并不完整，无法排除其中同样混有旧地址残留的可能。反之，本次现象发生在单一网络环境下，也无法据此断言它与之前的异常无关。二者表面相似、成因未明，本文选择分开记录、不做归并，留待更严谨的对照测试来确认。
排查意义：这个现象提醒，在 IPv6 排查过程中，不能仅根据 ipconfig 中出现多个 IPv6 地址就直接判断存在多个 IPv6 网络来源，需要进一步结合以下信息综合判断：
- 当前连接的 WiFi 网络；
- IPv6 地址是否可达（
curl.exe -6 https://api64.ipify.org）； - 默认路由（
Get-NetRoute -AddressFamily IPv6）；
jj- 地址有效状态（Get-NetIPAddress中 State 为 Preferred 还是 Deprecated）； - 切换网络后的变化（断开重连后旧地址是否消失）。
在 AP 模式下，链路中只有一个前缀来源，"出现多个 IPv6 地址"更大概率是地址保留残留，而不是多了一个 IPv6 出口——不必因此再开启一轮"双网络来源"排查。
第五阶段：Tailscale fallback 方案
前两个阶段的记录已经说明了问题：IPv6 出站稳定可用，P2P 打洞能建立直连但长期不稳定，原生入站不可控。在这样的环境下保证远程访问，需要一个不依赖 IPv6 入站开放的方案——这正是 Tailscale 最终被选为 fallback 的原因：出站可达即可建立连接，打洞成功走 P2P 直连，失败则退回 DERP 中转，访问通道始终存在。
由此，两篇文章构成了一个完整的系列：
1 | 上一篇：理想环境（主路由可 PPPoE 拨号）下的原生 IPv6 公网服务暴露 |
整体架构方案总结
从“二级路由跑通 IPv6”到“AP 模式降低复杂度”，这轮重构最终形成的家庭网络结构是：
1 | 江西移动光猫 |
在不改动光猫桥接、不获取光猫超密的前提下，远程访问由 Tailscale 兜底：能打洞时 P2P 直连，打洞失败时退回 DERP 中转——无论如何，家中的服务始终可达。
回头看这轮排查，有三条经验值得记住：
- 获取公网 IPv6 地址，不代表拥有完整的 IPv6 入站能力。 出站、P2P 打洞、原生入站是三个层级，需要分别验证，任何一层成功都不等于全部成功。
- 在无法控制运营商光猫配置时，减少 IPv6 中间节点比继续复杂调参更加可靠。 光猫是黑盒，就让链路里只留它一个控制点。
- Tailscale 不只是穿透工具，也可以作为家庭 IPv6 服务暴露失败时的可靠 fallback。 当入站不可控时，把远程访问交给 Tailscale 兜底，比持续和光猫搏斗更省心。
如果还要复用这套排查路径，两个实操细节值得记下：
- IPv6 能力分层验证：出站（
curl -6）、P2P 打洞（tailscale netcheck/tailscale ping）、原生入站分别验证——本文的结果是前两层成功、入站失败。 - 刷新 DNS 缓存：修改路由配置后及时在 Windows 执行
ipconfig /flushdns，否则旧的 DNS 租约可能让 AAAA 解析持续超时。
参考文章
基于原生 IPv6 与 NPM 实现 Win11 本地服务低延迟公网暴露h2-3 新版本开telnet的有会的吗？『 光猫FTTx技术交流区 』
注1：为什么在 Tailscale 中原生 IPv6 打洞比 DERP 快这么多？
DERP (Designated Encrypted Relay for Packets) 是 Tailscale 的中继节点。当通信双方均处于复杂的 NAT 后且缺乏公网 IPv4/v6 时，流量必须绕道公网中继服务器传输；而一旦双方拥有公网 IPv6，Tailscale 即可直接基于 UDP 端口建立端到端的点对点加密通道，省去中间所有中转节点。
