标签 IPv6 下的文章

家庭网络如何获取到公网IPv6

作者: 纯情
时间: 2026-01-30
分类: 网络
评论

家庭网络如何获取到公网IPv6

OpenWrt 作为二级路由时 IPv6 故障排查与配置总结报告

背景

基于笔者的实战经验总结而来.
供参考.
适用于 iStoreOS 和 openwrt.
版本是: 24.10

1. 问题概述

初始状态

网络拓扑：电信光猫（拨号主路由） → iStoreOS/OpenWrt（二级路由） → 终端设备（PC/手机）。
核心问题：终端设备通过 iStoreOS/OpenWrt无法获得 IPv6 互联网连接，但直接连接光猫或通过另一台普通二级路由则正常。
关键限制：无法调整电信光猫的任何设置。(电信不让, 调了也可能被远程调回去...)

根本原因分析

在光猫拨号并已启用 IPv6 的网络中，光猫本身是 IPv6 的路由通告（RA） 和 DHCPv6 服务器。iStoreOS/OpenWrt 作为二级路由，其正确的角色应是一个 “透明中继” ，负责将光猫下发的 IPv6 信息原样转发给内网设备，而非自己充当服务器。默认的 iStoreOS/OpenWrt 配置（LAN 口为“服务器模式”）会尝试自行分配 IPv6，导致与上层冲突，使终端设备无法获得有效的公网 IPv6 地址或路由。

2. 排查与解决流程

整个排查过程遵循了从基础到深入、从配置到服务的逻辑，下图清晰地展示了核心的诊断路径与解决步骤：

flowchart TD
    A[问题：通过OpenWrt无IPv6<br>但直连光猫正常] --> B{检查OpenWrt WAN口状态}
    
    B --> C{WAN口是否获取到<br>公网IPv6地址？<br>（240e:/2408:开头）}
    C -- 是 --> D[核心问题：LAN口配置模式错误]
    C -- 否 --> E[需检查物理连接与光猫IPv6服务]
    
    D --> F[关键修复：修改LAN口DHCPv6设置]
    F --> G[将模式从“服务器”改为“中继/混合”]
    G --> H[并勾选“始终通告默认路由”]
    
    H --> I{终端设备是否获得<br>公网IPv6地址？}
    I -- 否 --> J[深入排查]
    I -- 是 --> K{IPv6网络连通性测试<br>（如 test-ipv6.com）}
    
    subgraph J [深入排查步骤]
        J1[检查并清空ULA前缀]
        J2[确认关闭IPv6 DNS过滤]
        J3[检查防火墙规则<br>（关闭WAN口IP动态伪装）]
        J4[重启odhcpd服务<br>清理旧地址]
    end
    
    J --> I
    K -- 失败 --> L[进行端到端Ping测试<br>定位中断环节]
    L --> M[根据测试结果<br>调整防火墙或MTU]
    K -- 成功 --> N[🎉 问题解决]

    style A stroke:#f66,stroke-width:2px
    style N stroke:#0a0,stroke-width:2px

各阶段关键操作与指令

1. 信息收集阶段

检查 iStoreOS/OpenWrt WAN 口：确认其通过 DHCPv6 协议获取到了电信的公网 IPv6 地址（240e:3a3:...），证明上游信号正常。如下图:
检查 iStoreOS/OpenWrt LAN 口配置：发现其 路由通告 和 DHCPv6 服务 均处于 “服务器模式”，这是问题的根源。如下图:
检查其他设置：发现 IPv6 ULA 前缀 未清空，且 过滤 IPv6 AAAA 记录 被勾选，这些都会干扰正常使用。

2. 核心配置修正阶段

将 LAN 口 DHCPv6 设置为中继：将 路由通告服务 和 DHCPv6 服务 改为 “中继模式” 或 “混合模式”。修正后如下:
清空 ULA 前缀：在 全局网络选项 中删除自动生成的 ULA 前缀（fdd5:...），防止其干扰公网地址分配。
允许 IPv6 DNS 解析：在 DHCP/DNS 高级设置中，取消勾选 “过滤 IPv6 AAAA 记录”。
调整防火墙：在 防火墙 设置中，确保 wan 区域的 IP动态伪装（NAT） 被取消勾选，以减少对 IPv6 流量的潜在干扰。

3. 服务应用与调试阶段

通过 SSH 或 TTYD 终端执行命令，重启负责 IPv6 的服务并清理旧地址：
```
/etc/init.d/odhcpd restart
ip -6 addr flush dev br-lan scope global
```

关键缺失项的发现：尽管终端设备获得了公网 IPv6 地址（240e:...），但 ipconfig /all 显示缺少 IPv6 默认网关。这直接导致数据包无法路由出去。这时候我的电脑显示如下:

连接特定的 DNS 后缀 . . . . . . . : lan
   IPv6 地址 . . . . . . . . . . . . : 240e:3a3:xxxx
   IPv6 地址 . . . . . . . . . . . . : fdd5:3075:xxx
   临时 IPv6 地址. . . . . . . . . . : 240e:3a3:xxx
   临时 IPv6 地址. . . . . . . . . . : fdd5:3075:xxx
   本地链接 IPv6 地址. . . . . . . . : fe80::1ba8:xxx
   IPv4 地址 . . . . . . . . . . . . : 192.168.3.246
   子网掩码  . . . . . . . . . . . . : 255.255.255.0
   默认网关. . . . . . . . . . . . . : 192.168.3.1 (缺少 **IPv6 默认网关**)

访问 <test-ipv6.com> 结果:

你的公网 IPv4 地址是 x.x.x.x


你的运营商（ISP）是 CHINANET-BACKBONE xxxx


没有检测到 IPv6 地址 [更多信息]


你只接入了 IPv4 互联网，不能访问纯 IPv6 网站。


可向运营商咨询如何使用 IPv6，实现最佳的网络性能。 [更多信息]


你的 DNS 服务器（可能由运营商提供）已经接入 IPv6 互联网了

4. 最终解决

返回 iStoreOS/OpenWrt LAN 口 DHCPv6 设置，找到并勾选 “始终通告默认路由” 选项。如下图:

保存应用后，终端设备立即获得了正确的 IPv6 默认网关（fe80::...），IPv6 互联网连接完全恢复。如下图:

DHCPv6 IAID . . . . . . . . . . . : 10483xxxxx
   DHCPv6 客户端 DUID  . . . . . . . : 00-01-00-01-26-xxxxx
   DNS 服务器  . . . . . . . . . . . : 192.168.3.1
                                       fe80::xxxxxx%28
                                       240e:3a3:xxxxx
                                       fdd5:xxxxxx

访问 <test-ipv6.com> 结果:

你的公网 IPv4 地址是 xxxxx


你的公网 IPv6 地址是 240e:3a3:xxxxx


你的运营商（ISP）是 CHINANET-BACKBONE xxxx


你已接入 IPv6，因此我们增加了一个标签页，显示你能否访问其他 IPv6 网站。[更多信息]


你的 DNS 服务器（可能由运营商提供）已经接入 IPv6 互联网了。
IPv6 状况评分
10/10    此分数表示你的系统对 IPv6 的支持程度和稳定性
点击查看 测试数据

3. 最终有效配置清单（iStoreOS/OpenWrt LuCI 界面）

配置位置	需修改的项	推荐设置	作用说明
网络 -> 接口 -> LAN -> DHCP服务器 -> IPv6设置	路由通告服务	`中继模式` 或 `混合模式`	转发光猫的RA报文，而非自行广播。
	DHCPv6 服务	`中继模式` 或 `混合模式`	转发光猫的DHCPv6地址分配。
	NDP 代理	`已禁用`	在简单中继网络中通常不需要。
	始终通告默认路由	`勾选`	关键！确保终端设备获得IPv6网关。
网络 -> 接口 -> 全局网络选项	IPv6 ULA 前缀	`清空`	避免生成本地地址，优先使用公网地址。
网络 -> DHCP/DNS -> 高级设置	过滤 IPv6 AAAA 记录	`取消勾选`	允许DNS服务器返回IPv6地址。
网络 -> 防火墙 -> 区域 (WAN)	IP动态伪装（NAT）	`取消勾选`	IPv6通常不需要NAT，避免不必要的转换。

4. 核心原理总结

中继 vs 服务器：在无法控制主路由（光猫）的拓扑中，二级路由的 IPv6 必须使用 “中继” 模式。它像一座桥梁，只传递信息，不自行决定。
地址分配顺序：系统会优先使用公网 IPv6 地址（GUA）。只有当中继失败、无法收到公网前缀时，设备才会退而求其次地使用 ULA 本地地址（fd 或 fdd 开头）。初期获得的 fdd5: 地址正是中继失败的标志。
路由通告的重要性：IPv6 不仅依赖地址，更依赖路由。“始终通告默认路由” 选项确保路由器告诉内网设备：“我是你们通往 IPv6 互联网的出口”。缺少这一步，设备有地址也无法上网。
防火墙差异：IPv6 的设计更倾向于端到端的直接通信，因此其防火墙策略与 IPv4（普遍使用NAT）有较大不同，通常无需也不建议对 IPv6 使用“动态伪装”（NAT）。

5. 经验与建议

排查顺序：遵循 “先 WAN 后 LAN，先地址后路由” 的原则。先确认上级有信号（WAN口有公网IP），再排查内部转发（LAN口中继配置），最后检查路由和防火墙。
配置备份：在 iStoreOS/OpenWrt 中，一旦配置成功，建议立即通过 “系统” -> “备份/升级” 生成一个备份文件。未来升级或重置后可以快速恢复。
测试工具：善用以下工具进行精准定位：
- ipconfig /all 或 ifconfig：查看本地地址和网关。
- ping -6 <目标>：测试 IPv6 连通性。
- test-ipv6.com：一站式综合测试。
潜在优化：如果网络稳定，可以考虑在 LAN 口的 IPv6 设置中，将 路由通告服务 和 DHCPv6 服务 从 混合模式 改回更纯粹的 中继模式，以减少 iStoreOS/OpenWrt 本身的参与度，理论上有更好的稳定性。

通过以上步骤，笔者成功地在一个受限制的网络环境中，将 iStoreOS/OpenWrt 配置为了一个合格的 IPv6 中继节点，使所有内网设备都能无缝接入 IPv6 互联网。这套方法对于任何品牌的光猫（桥接或路由模式）下使用 iStoreOS/OpenWrt 作为二级路由的情况，都具有普遍的参考价值。

贡献一个江苏联通宽带跑 PT 进小黑屋的样本

作者: 纯情
时间: 2026-01-30
分类: 网络
评论

TLDR：坐标南京联通，之前改了桥接，要了公网 IP 。今天晚上因为 PT 先被断网，后被关进小黑屋限速。

晚上吃个饭回来发现家里网断了，进路由器发现只获取到了一个/64 的 ipv6 地址，无论怎么重启光猫还是路由器都无法获取 ipv4 地址。自己排查了一个多小时毫无头绪。

无奈联系装维，装维说我的宽带账号下有多个设备同时拨号，导致拨号失败(奇怪的是我光猫下面只有一台路由器，也并未配置多拨/多 wan 口)。装维让我把路由器拔了等半个小时，我半个小时后重新插上路由器问题依旧存在，路由器拨号还是只能获取到 ipv6 ，装维说那就明天上门看看。

此时我突发奇想：如果在路由器里把 ipv6 禁用了会怎么样呢？没想到禁用后成功获取到 ipv4 ，也能正常打开网页了。

正开心地告诉装维弄好了明天不用来了，测速发现网络延迟极高而网速极低（千兆宽带，用 ustc 测速站测得下行两位数，上行个位数，延迟三位数）。

又 call 装维，装维问我最近有没有用软件下载，让我拍电脑的使用流量统计给他看用量排行前几名的软件，并让我最近不要大流量使用。

此刻我恍然大悟，原来平时在网上看到的宽带被运营商限速的故事终于轮到我了。这两天迷上怪奇物语，从 PT 一口气美美下载了一到五季的 4K HDR 片源，发现分享率掉了一些又下了些热门资源刷上传，没想到两天之内下载 900 多 G ，上传不到 500G 就被联通噶掉了。又搜了一下此刻的公网 ip 段，116.147.x.x，果不其然进了小黑屋。

这何尝不是一种 Stranger Things ╮（╯＿╰）╭

25 分钟把 IPv6“带偏”全网：Cloudflare这次玩大了！

作者: 纯情
时间: 2026-01-24
分类: 资讯
评论

这是一场典型的“看起来只是删了几行配置，实际把闸门拆了”的事故。

2026 年 1 月 22 日，Cloudflare 在美国迈阿密（Miami）的一个数据中心路由器上，因为自动化路由策略配置错误，把一部分原本只该在内部传播的 IPv6 BGP 前缀意外对外宣告了出去，形成 BGP Route Leak（路由泄漏）。事故持续 25 分钟，导致迈阿密骨干链路拥塞、部分客户流量丢包/延迟升高，同时还把一些外部网络的流量“误导”进迈阿密，最终被 Cloudflare 的防火墙过滤规则丢弃（峰值丢了约 12Gbps 入口流量）。

听起来像网络圈的“蝴蝶效应”：你只是在路由策略里挪了一块砖，结果半个街区的车流都改道了🚧。

什么是 Route Leak：

不是“断网”，是“指错路”

路由泄漏的本质非常直白：某个 AS 告诉整个互联网：来我这走，我能带你到终点——但它其实不该这么说。

BGP 里有个“潜规则”：从上游（provider）和对等（peer）学到的路由，不能再转发给另一个 peer 或 provider，否则就违反所谓的 valley-free routing。一旦违反，流量会被吸到不该承载它的网络上，轻则拥塞、抖动，重则大范围不可达。

这次事故就是类似的“指路牌摆反了”：Cloudflare 在迈阿密把从一些 peer 学到的路由，又转手“推销”给了其他 peer 和 transit provider，属于 RFC7908 里提到的多种 route leak 类型混合体（简单理解：该往下游走的路，被错误地往上/平行扩散了）。

时间线：从合并代码到止血，只花了 25 分钟（但足够难受）

这次节奏很“现代工程化”：代码合并 → 自动化跑配置 → 线上立刻出事 → 人肉回滚止血 → 再回滚代码。

Time (UTC)	Event
2026-01-22 19:52 UTC	触发路由策略 bug 的变更合并进网络自动化代码仓库
2026-01-22 20:25 UTC	自动化在迈阿密单台边缘路由器运行，开始向 transit/peer 异常宣告（IMPACT START）
2026-01-22 20:40 UTC	网络团队开始排查迈阿密的异常 BGP 广告
2026-01-22 20:44 UTC	事故升级，开始协同处置
2026-01-22 20:50 UTC	操作员手动回滚坏配置，并暂停该路由器的自动化（IMPACT STOP）
2026-01-22 21:47 UTC	触发泄漏的代码提交被回滚
2026-01-22 22:07 UTC	确认自动化恢复健康，可重新在迈阿密路由器运行
2026-01-22 22:40 UTC	迈阿密单台路由器解除自动化暂停

“删掉 Bogotá 的前缀”怎么删成了“全都放行”？

事故起点其实很合理：Cloudflare 之前会把一部分 IPv6 流量经迈阿密转发到哥伦比亚波哥大（Bogotá）数据中心，但随着基础设施升级，这个绕路不需要了，于是要把 Bogotá 相关前缀从迈阿密撤掉。

变更 diff 大概长这样（看着很“无害”对吧？）：

[edit policy-options policy-statement 6-COGENT-ACCEPT-EXPORT term ADV-SITELOCAL-GRE-RECEIVER from]
-      prefix-list 6-BOG04-SITE-LOCAL;
[edit policy-options policy-statement 6-COMCAST-ACCEPT-EXPORT term ADV-SITELOCAL-GRE-RECEIVER from]
-      prefix-list 6-BOG04-SITE-LOCAL;
[edit policy-options policy-statement 6-GTT-ACCEPT-EXPORT term ADV-SITELOCAL-GRE-RECEIVER from]
-      prefix-list 6-BOG04-SITE-LOCAL;
[edit policy-options policy-statement 6-LEVEL3-ACCEPT-EXPORT term ADV-SITELOCAL-GRE-RECEIVER from]
-      prefix-list 6-BOG04-SITE-LOCAL;
[edit policy-options policy-statement 6-PRIVATE-PEER-ANYCAST-OUT term ADV-SITELOCAL from]
-      prefix-list 6-BOG04-SITE-LOCAL;
[edit policy-options policy-statement 6-PUBLIC-PEER-ANYCAST-OUT term ADV-SITELOCAL from]
-      prefix-list 6-BOG04-SITE-LOCAL;
[edit policy-options policy-statement 6-PUBLIC-PEER-OUT term ADV-SITELOCAL from]
-      prefix-list 6-BOG04-SITE-LOCAL;
[edit policy-options policy-statement 6-TELEFONICA-ACCEPT-EXPORT term ADV-SITELOCAL-GRE-RECEIVER from]
-      prefix-list 6-BOG04-SITE-LOCAL;
[edit policy-options policy-statement 6-TELIA-ACCEPT-EXPORT term ADV-SITELOCAL-GRE-RECEIVER from]
-      prefix-list 6-BOG04-SITE-LOCAL;

问题就出在：把 prefix-list 条件删掉后，策略项的匹配条件变得过于宽松，直接变成了“只要是 internal route-type，我就 accept，然后对外 export”。

policy-options policy-statement 6-TELIA-ACCEPT-EXPORT {
    term ADV-SITELOCAL-GRE-RECEIVER {
        from route-type internal;
        then {
            community add STATIC-ROUTE;
            community add SITE-LOCAL-ROUTE;
            community add MIA01;
            community add NORTH-AMERICA;
            accept;
        }
    }
}

这里有个 JunOS/JunOS EVO 的坑点：route-type internal 会匹配所有非 external 的路由类型，包括 IBGP 学到的内部路由。于是本来只想“内部可见”的 IPv6 前缀，被这条 export policy 直接放行对外广播了。

一句话：原来靠 prefix-list 当“门禁”，删了门禁后，剩下的条件相当于“只要你是小区住户，就能把快递站里的所有包裹搬出去”——策略写得再“优雅”，accept 一落地就成了事故开关🔘。

影响面：拥塞、丢包、延迟上升，还顺带“误伤”外部网络

当迈阿密开始对外宣告这些不该宣告的 IPv6 前缀后，互联网路由收敛会让部分流量被吸到迈阿密。结果就是：

迈阿密—亚特兰大骨干链路出现拥塞，导致一些 Cloudflare 客户流量出现更高的延迟/丢包
被泄漏的前缀所属网络（外部网络）的一部分流量也被引向迈阿密，但 Cloudflare 路由器的防火墙过滤器只允许 Cloudflare/客户相关前缀的流量，导致这部分流量被丢弃（峰值约 12Gbps）

同时，路由泄漏的证据也能在路由收集器的历史数据里看到，比如这段 monocle 检索结果（注意 AS path 中 Cloudflare AS13335 出现在不该出现的位置上）：

➜  ~ monocle search --start-ts 2026-01-22T20:24:00Z --end-ts 2026-01-22T20:30:00Z --as-path ".*13335[ d$]32934$*"
A|1769113609.854028|2801:14:9000::6:4112:1|64112|2a03:2880:f077::/48|64112 22850 174 3356 13335 32934|IGP|2801:14:9000::6:4112:1|0|0|22850:65151|false|||pit.scl
A|1769113609.854028|2801:14:9000::6:4112:1|64112|2a03:2880:f091::/48|64112 22850 174 3356 13335 32934|IGP|2801:14:9000::6:4112:1|0|0|22850:65151|false|||pit.scl
A|1769113609.854028|2801:14:9000::6:4112:1|64112|2a03:2880:f16f::/48|64112 22850 174 3356 13335 32934|IGP|2801:14:9000::6:4112:1|0|0|22850:65151|false|||pit.scl
A|1769113609.854028|2801:14:9000::6:4112:1|64112|2a03:2880:f17c::/48|64112 22850 174 3356 13335 32934|IGP|2801:14:9000::6:4112:1|0|0|22850:65151|false|||pit.scl
A|1769113609.854028|2801:14:9000::6:4112:1|64112|2a03:2880:f26f::/48|64112 22850 174 3356 13335 32934|IGP|2801:14:9000::6:4112:1|0|0|22850:65151|false|||pit.scl
A|1769113609.854028|2801:14:9000::6:4112:1|64112|2a03:2880:f27c::/48|64112 22850 174 3356 13335 32934|IGP|2801:14:9000::6:4112:1|0|0|22850:65151|false|||pit.scl
A|1769113609.854028|2801:14:9000::6:4112:1|64112|2a03:2880:f33f::/48|64112 22850 174 3356 13335 32934|IGP|2801:14:9000::6:4112:1|0|0|22850:65151|false|||pit.scl
A|1769113583.095278|2001:504:d::4:9544:1|49544|2a03:2880:f17c::/48|49544 1299 3356 13335 32934|IGP|2001:504:d::4:9544:1|0|0|1299:25000 1299:25800 49544:16000 49544:16106|false|||route-views.isc
A|1769113583.095278|2001:504:d::4:9544:1|49544|2a03:2880:f27c::/48|49544 1299 3356 13335 32934|IGP|2001:504:d::4:9544:1|0|0|1299:25000 1299:25800 49544:16000 49544:16106|false|||route-views.isc
A|1769113583.095278|2001:504:d::4:9544:1|49544|2a03:2880:f091::/48|49544 1299 3356 13335 32934|IGP|2001:504:d::4:9544:1|0|0|1299:25000 1299:25800 49544:16000 49544:16106|false|||route-views.isc
A|1769113584.324483|2001:504:d::19:9524:1|199524|2a03:2880:f091::/48|199524 1299 3356 13335 32934|IGP|2001:2035:0:2bfd::1|0|0||false|||route-views.isc
A|1769113584.324483|2001:504:d::19:9524:1|199524|2a03:2880:f17c::/48|199524 1299 3356 13335 32934|IGP|2001:2035:0:2bfd::1|0|0||false|||route-views.isc
A|1769113584.324483|2001:504:d::19:9524:1|199524|2a03:2880:f27c::/48|199524 1299 3356 13335 32934|IGP|2001:2035:0:2bfd::1|0|0||false|||route-views.isc
{trimmed}

别再迷信“自动化=不会错”

这次事故最扎心的一点是：自动化没有坏，坏的是策略生成逻辑里那个“空条件”缺口。自动化把错误放大得更快、更一致、更“全自动”，所以也更需要“刹车系统”。

Cloudflare 的改进方向很有代表性，基本可以当成网络自动化团队的“安全 checklist”：

立刻修补路由策略自动化里导致错误放行的缺陷，并在同类风险点上补洞
在路由策略里加更强的基于 BGP community 的防护：对外 export policy 上明确拒绝“来自 peer/provider 的路由”
在 CI/CD 里做自动化策略评估：重点抓“空/错误的 policy term”（像这次就是删 prefix-list 后 term 还 accept）
提前告警：更早发现配置异常与自动化变更的负面效应
更长期的路由安全：验证并推进 RFC9234（BGP Roles / Only-to-Customer）等机制，从“协议能力”层面降低本地 AS route leak 的概率
促进 RPKI ASPA 之类能力的采用，让异常 AS path 更容易被自动拒绝

结语

网络世界最怕的不是“改配置”，是“改配置还以为没事”😅

这场 25 分钟的泄漏，杀伤力并不靠持续时间，而靠 BGP 的传播速度 + 流量的惯性。更现实的是：只要系统允许“内部路由被 accept 并 export”，那就等于把“内部车道”直接连到了高速入口——迟早会堵。

真正能让系统更稳的，不是“以后小心点”，而是工程化地把风险钉死：

关键策略项不能出现“条件被删空但仍 accept”
对外 export 必须能识别并拒绝来自 peer/provider 的路由
自动化要配“策略单测 + 变更评估 + 审计与回滚”三件套

毕竟，互联网的路由不是你家路口的指示牌，摆歪了，整座城市都可能跟着绕路。😵‍💫

喜欢就奖励一个“👍”和“在看”呗~

预算 200，求推荐能刷 openwrt 的路由器。

作者: 纯情
时间: 2026-01-21
分类: 网络
评论

预算 200 元，之所以刷 openwrt 是为了给家里 ipv6 设置出入站规则，廉价路由器自带固件只有开关防火墙功能。

sillytavern 设置域名 ipv6 优先教程

作者: 纯情
时间: 2026-01-12
分类: 网络
评论

背景：
昨天开始就频繁的无法连接位于海外 vps 的反代，然后 ping 一下发现丢包率好高，今天突发奇想我的 vps 是带 ipv6 的，因为我部署酒馆的服务器是家庭宽带有公网的 ipv6，我就 ping6 试了一下发现延迟低不少而且丢包率为 0，以此开始以下环节。

适用人群：
使用国内 nas 或者小主机等在自己家部署的酒馆，也就是家庭网络，现在大部分家庭网络都有公网的 ipv6

教程开始：

检查服务器主机当前 DNS 解析顺序

getent ahosts 你的域名

看输出结果是 ipv6 在前还是在后

1-1.ipv6 在下时，设置 ipv6 优先
查询配置文件

cat /etc/gai.conf

如果出现以下默认配置则代表是 ipv6 优先

#precedence  ::1/128       50 #precedence  ::/0          40 #precedence  2002::/16     30 #precedence ::/96          20 #precedence ::ffff:0:0/96  10

如果是出现以下，需要给前面加上 #号

precedence ::ffff:0:0/96 100

检查 Docker 是否启用 IPv6

docker network inspect bridge | grep -i ipv6

出现以下则代表开启
“EnableIPv6”: true,

2-1. 开启 docker 的 ipv6
1Panel 面板
docker 界面设置，开启 ipv6，子网 fd00::/80
并重启 docker 和容器

检查容器是否有 IPv6 地址

docker exec 容器名（sillytavern） ip -6 addr

如果出现
enp1s0 和 ipv6 地址则代表获取成功

3-1. 测试容器 ipv6 连通性

docker exec 容器名 ping6 -c 2 你的ipv6地址

设置容器 IPv6 优先级
酒馆是 Alpine 容器，在环境变量里添加

NODE_OPTIONS=--dns-result-order=ipv6first

因为 docker 的网段设置是默认不带 ipv6 的所有在 1panel 里添加环境变量的时候，把网络段设置为 host
在 ssh 里输入如下

docker exec 容器名 node -e "

2const dns = require('dns');

3dns.lookup('你的域名', { all: true }, (err, addrs) => {

4  console.log(addrs);

5});

6"
7

ipv6 在前则设置成功
在验证一下

docker exec 容器名 node -e "

const dns = require('dns');

dns.lookup('你的域名', (err, addr, family) => {

  console.log('实际使用 IP:', addr);

  console.log('IP 版本:', family === 6 ? 'IPv6' : 'IPv4');

});

"

结果显示的是实际使用 ip：你的公网 ipv6 则成功

修改容器的 config.yaml

protocol: ipv4: true ipv6: true dnsPreferIPv6: true

📌 转载信息

来源：
https://linux.do/t/topic/1431146

原作者：
ak7876

转载时间：
2026/1/12 15:39:49

港仔日本 CPE 5G 蜂窩網絡 Mobile 5G 家宽 KDDI 测评

作者: 纯情
时间: 2026-01-12
分类: 网络
评论

测试一下港仔的 KDDI/au 5G Mobile VPS 产品，少数的日本蜂窩網絡 Mobile 家宽，ip 质量优秀，常规流媒体和本土流媒体基本全都解锁，机器性能强劲，i912900H 的 CPU 性能不错，IO 也不错。IPV4 三网不可直连，推荐中转，IPV6 部分地区可直连，带宽应该是 200Mbps，不过都买了这么贵的家宽了，应该不差这点中转费用了

这个机器为双 ip 策略

入口：idc V4入口或者KDDI家宽V6入 //可以自带IPV4入口，直接对接你的线路机器
出口：KDDI家宽V4出或者家宽V6出

测试配置为

2C2G 8GB 
CPE 5G蜂窩網絡Mobile 5G
IPv4 *1 & IPv6 /64 SLAAC
1T流量「工单免费重置」
98刀/月

网络质量

IPV6 入

bestvm V4 入

测了一下日本本土互联，下载速度非常一般，这台前置貌似是限速了

BageVM → Boil.5G PCE

23 packets transmitted, 23 received, 0% packet loss, time 22531ms
rtt min/avg/max/mdev = 0.321/0.405/0.507/0.046 ms

[ ID] Interval           Transfer     Bitrate
[  5]   0.00-1.00   sec  3.02 MBytes  25.3 Mbits/sec                  
[  5]   1.00-2.00   sec  4.07 MBytes  34.1 Mbits/sec                  
[  5]   2.00-3.00   sec  4.07 MBytes  34.2 Mbits/sec                  
[  5]   3.00-4.00   sec  2.11 MBytes  17.7 Mbits/sec                  
[  5]   4.00-5.00   sec  2.64 MBytes  22.2 Mbits/sec                  
[  5]   5.00-6.00   sec  4.36 MBytes  36.6 Mbits/sec                  
[  5]   6.00-7.00   sec  5.04 MBytes  42.2 Mbits/sec                  
[  5]   7.00-8.00   sec  11.9 MBytes   100 Mbits/sec                  
[  5]   8.00-9.00   sec  12.3 MBytes   103 Mbits/sec                  
[  5]   9.00-10.00  sec  1.54 MBytes  12.9 Mbits/sec                  
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bitrate         Retr
[  5]   0.00-10.03  sec  51.3 MBytes  42.9 Mbits/sec  6051             sender
[  5]   0.00-10.00  sec  51.1 MBytes  42.8 Mbits/sec                  receiver

[ ID] Interval           Transfer     Bitrate
[  5]   0.00-1.00   sec  7.88 MBytes  66.1 Mbits/sec                  
[  5]   1.00-2.00   sec  9.15 MBytes  76.8 Mbits/sec                  
[  5]   2.00-3.00   sec  15.2 MBytes   127 Mbits/sec                  
[  5]   3.00-4.00   sec  11.3 MBytes  95.0 Mbits/sec                  
[  5]   4.00-5.00   sec  3.80 MBytes  31.9 Mbits/sec                  
[  5]   5.00-6.00   sec  2.58 MBytes  21.7 Mbits/sec                  
[  5]   6.00-7.00   sec  2.29 MBytes  19.2 Mbits/sec                  
[  5]   7.00-8.00   sec  15.2 MBytes   127 Mbits/sec                  
[  5]   8.00-9.00   sec  22.0 MBytes   185 Mbits/sec                  
[  5]   9.00-10.00  sec  8.12 MBytes  68.2 Mbits/sec                  
[  5]  10.00-11.00  sec  2.39 MBytes  20.1 Mbits/sec                  
[  5]  11.00-12.00  sec  2.94 MBytes  24.6 Mbits/sec                  
[  5]  12.00-13.00  sec  2.32 MBytes  19.4 Mbits/sec                  
[  5]  13.00-14.00  sec   786 KBytes  6.44 Mbits/sec                  
[  5]  14.00-15.00  sec   708 KBytes  5.80 Mbits/sec                  
[  5]  15.00-16.00  sec   499 KBytes  4.09 Mbits/sec                  
[  5]  16.00-17.00  sec   551 KBytes  4.52 Mbits/sec                  
[  5]  17.00-18.00  sec   955 KBytes  7.82 Mbits/sec                  
[  5]  18.00-19.00  sec  1.65 MBytes  13.8 Mbits/sec                  
[  5]  19.00-20.00  sec   878 KBytes  7.19 Mbits/sec                  
[  5]  20.00-21.00  sec   672 KBytes  5.51 Mbits/sec                  
[  5]  21.00-22.00  sec   414 KBytes  3.39 Mbits/sec                  
[  5]  22.00-23.00  sec   487 KBytes  3.99 Mbits/sec                  
[  5]  23.00-24.00  sec  1.46 MBytes  12.3 Mbits/sec                  
[  5]  24.00-25.00  sec  5.53 MBytes  46.4 Mbits/sec                  
[  5]  25.00-26.00  sec  1.12 MBytes  9.42 Mbits/sec                  
[  5]  26.00-27.00  sec  1.08 MBytes  9.07 Mbits/sec                  
[  5]  27.00-28.00  sec   554 KBytes  4.54 Mbits/sec                  
[  5]  28.00-29.00  sec   373 KBytes  3.06 Mbits/sec                  
[  5]  29.00-30.00  sec   313 KBytes  2.57 Mbits/sec                  
[  5]  30.00-31.00  sec  5.22 MBytes  43.8 Mbits/sec                  
[  5]  31.00-32.00  sec  1.83 MBytes  15.4 Mbits/sec                  
[  5]  32.00-33.00  sec  15.4 MBytes   130 Mbits/sec                  
[  5]  33.00-34.00  sec  7.77 MBytes  65.2 Mbits/sec                  
[  5]  34.00-35.00  sec  7.04 MBytes  59.0 Mbits/sec                  
[  5]  35.00-36.00  sec  4.08 MBytes  34.2 Mbits/sec                  
[  5]  36.00-37.00  sec  2.04 MBytes  17.1 Mbits/sec                  
[  5]  37.00-38.00  sec  1.27 MBytes  10.7 Mbits/sec                  
[  5]  38.00-39.00  sec   554 KBytes  4.54 Mbits/sec                  
[  5]  39.00-40.00  sec  1.16 MBytes  9.73 Mbits/sec                  
[  5]  40.00-41.00  sec  6.31 MBytes  52.9 Mbits/sec                  
[  5]  41.00-42.00  sec  5.74 MBytes  48.2 Mbits/sec                  
[  5]  42.00-43.00  sec  4.96 MBytes  41.7 Mbits/sec                  
[  5]  43.00-44.00  sec  3.92 MBytes  32.8 Mbits/sec                  
[  5]  44.00-45.00  sec  3.29 MBytes  27.6 Mbits/sec                  
[  5]  45.00-46.00  sec  2.29 MBytes  19.2 Mbits/sec                  
[  5]  46.00-47.00  sec  3.12 MBytes  26.2 Mbits/sec                  
[  5]  47.00-48.00  sec  8.99 MBytes  75.4 Mbits/sec                  
[  5]  48.00-49.00  sec  13.0 MBytes   109 Mbits/sec                  
[  5]  49.00-50.00  sec  5.77 MBytes  48.4 Mbits/sec                  
[  5]  50.00-51.00  sec  1.10 MBytes  9.25 Mbits/sec                  
[  5]  51.00-52.00  sec  2.92 MBytes  24.5 Mbits/sec                  
[  5]  52.00-53.00  sec  2.81 MBytes  23.6 Mbits/sec                  
[  5]  53.00-54.00  sec  1.82 MBytes  15.3 Mbits/sec                  
[  5]  54.00-55.00  sec   458 KBytes  3.75 Mbits/sec                  
[  5]  55.00-56.00  sec   509 KBytes  4.17 Mbits/sec                  
[  5]  56.00-57.00  sec   501 KBytes  4.10 Mbits/sec                  
[  5]  57.00-58.00  sec   559 KBytes  4.58 Mbits/sec                  
[  5]  58.00-59.00  sec   819 KBytes  6.71 Mbits/sec                  
[  5]  59.00-60.00  sec   665 KBytes  5.45 Mbits/sec                  
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bitrate         Retr
[  5]   0.00-60.03  sec   239 MBytes  33.4 Mbits/sec  28034             sender
[  5]   0.00-60.00  sec   239 MBytes  33.4 Mbits/sec                  receiver

ip 质量

TK 是解锁的啊，这个脚本有点问题

IPV4 质量

IPV6 质量

常见流媒体解锁

---------------流媒体解锁--感谢oneclickvirt/UnlockTests测试----------------
Can not detect IPv6 Address
测试时间:  2026-01-11 20:15:17
IPV4:
============[ 跨国平台 ]============
Apple                     YES (Region: JPN)
BingSearch                YES (Region: JP)
Claude                    YES
Dazn                      YES (Region: JP)
Disney+                   YES (Region: JP)
Gemini                    YES (Region: JP)
GoogleSearch              YES
Google Play Store         YES (Region: JP)
IQiYi                     YES (Region: JP)
Instagram Licensed Audio  YES
KOCOWA                    NO
MetaAI                    YES (Region: US)
Netflix                   YES (Region: JP)
Netflix CDN               JP
OneTrust                  YES (Region: JP TOKYO)
ChatGPT                   YES (Region: JP)
Paramount+                YES
Amazon Prime Video        YES (Region: JP)
Reddit                    YES
SonyLiv                   Banned
Sora                      YES (Region: JP)
Spotify Registration      NO
Steam Store               YES (Community Available) (Region: JP)
TVBAnywhere+              YES (Region: JP)
TikTok                    YES (Region: JP)
Viu.com                   YES
Wikipedia Editability     YES
YouTube Region            YES (Region: JP)
YouTube CDN               kddi - HND
---------------------TikTok解锁--感谢lmc999的源脚本---------------------
 Tiktok Region:         【JP】

细分流媒体解锁

 ** 正在测试 IPv4 解锁情况
--------------------------------
 ** 您的网络为: au one net (59.132.*.*)
============[ Multination ]============
 Dazn:                                  Yes (Region: JP)
 Disney+:                               Yes (Region: JP)
 Netflix:                               Yes (Region: JP)
 YouTube Premium:                       Yes (Region: JP)
 Amazon Prime Video:                    Yes (Region: JP)
 TVBAnywhere+:                          Yes
 Spotify Registration:                  No
 OneTrust Region:                       JP [Tokyo]
 iQyi Oversea Region:                   JP
 Bing Region:                           JP (Risky)
 Apple Region:                          JP
 YouTube CDN:                           [KDDI] in [Tokyo]
 Netflix Preferred CDN:                 Tokyo
 ChatGPT:                               Yes
 Google Gemini:                         Yes (Region: JPN)
 Claude:                                Yes
 Wikipedia Editability:                 Yes
 Google Play Store:                     Japan 
 Google Search CAPTCHA Free:            Yes
 Steam Currency:                        JPY
 ---Forum---
 Reddit:                                Yes
 ---Game---
 SD Gundam G Generation Eternal:        Yes
=======================================
===============[ Japan ]===============
 DMM:                                   Yes
 DMM TV:                                Yes
 Abema.TV:                              Yes (Region: JP)
 Niconico:                              Failed (Error: PAGE ERROR)
 Telasa:                                Yes
 U-NEXT:                                Yes
 Hulu Japan:                            Yes
 TVer:                                  Failed (Error: PAGE ERROR)
 Lemino:                                Yes
 AnimeFesta:                            Yes
 WOWOW:                                 Failed (Error: PAGE ERROR 1)
 VideoMarket:                           Yes
 D Anime Store:                         Yes
 FOD(Fuji TV):                          Yes
 Radiko:                                Yes (City: KAGOSHIMA)
 Karaoke@DAM:                           Yes
 J:com On Demand:                       Yes
 WATCHA:                                Yes
 Rakuten TV JP:                         Failed (Error: PAGE ERROR 1)
 ---Game---
 Kancolle Japan:                        Failed (Network Connection)
 Pretty Derby Japan:                    Yes
 Konosuba Fantastic Days:               Failed (Network Connection)
 Princess Connect Re:Dive Japan:        Yes
 Project Sekai: Colorful Stage:         Yes
 ---Music---
 Mora:                                  Yes
 music.jp:                              Yes
 ---Forum---
 EroGameSpace:                          Yes
=======================================

常见 IP 库结果

-------------IP质量检测--基于oneclickvirt/securityCheck使用--------------
数据仅作参考，不代表100%准确，如果和实际情况不一致请手动查询多个数据库比对
以下为各数据库编号，输出结果后将自带数据库来源对应的编号
ipinfo数据库  [0] | scamalytics数据库 [1] | virustotal数据库   [2] | abuseipdb数据库   [3] | ip2location数据库    [4]
ip-api数据库  [5] | ipwhois数据库     [6] | ipregistry数据库   [7] | ipdata数据库      [8] | db-ip数据库          [9]
ipapiis数据库 [A] | ipapicom数据库    [B] | bigdatacloud数据库 [C] | dkly数据库        [D] | ipqualityscore数据库 [E]
ipintel数据库 [F] | ipfighter数据库   [G] | fraudlogix数据库   [H] | cloudflare数据库  [I] |
IPV4:
安全得分:
信任得分(越高越好): 100 [8] 
VPN得分(越低越好): 0 [8] 
代理得分(越低越好): 0 [8] 
社区投票-无害: 0 [2] 
社区投票-恶意: 0 [2] 
威胁得分(越低越好): 0 [8] 
欺诈得分(越低越好): 28 [E] 
滥用得分(越低越好): 0 [3] 
威胁级别: low [9] 
流量占比: 真人(越高越好)96% [I] 机器人(越低越好)3% [I]
黑名单记录统计:(有多少黑名单网站有记录):
无害记录数: 0 [2]  恶意记录数: 0 [2] 可疑记录数: 0 [2]  无记录数: 93 [2] 
安全信息:
使用类型: unknown [C] business [9] cellular [3] isp [0 7 8]
公司类型: isp [0 7] 
浏览器类型: 主流37% 其他62% [I] 
设备类型: 桌面27% 移动72% 其他0% [I] 
操作系统类型: 主流98% 其他1% [I] 
是否云提供商: No [7 D] 
是否数据中心: No [0 5 8 C G] 
是否移动设备: No [5 G] Yes [C E]
是否代理: Yes [G] No [0 4 5 7 8 9 C D E]
是否VPN: No [0 7 C D E G] 
是否Tor: No [0 3 7 8 C D E] 
是否Tor出口: No [7 D] 
是否网络爬虫: No [9 E]
是否匿名: No [7 8 D] 
是否攻击者: No [7 8 D] 
是否滥用者: No [7 8 C D E] 
是否威胁: No [7 8 C D] 
是否中继: No [0 7 8 C D] 
是否Bogon: No [7 8 C D] 
是否机器人: No [E] 
Google搜索可行性：NO
------------邮件端口检测--基于oneclickvirt/portchecker开源------------
Platform  SMTP  SMTPS POP3  POP3S IMAP  IMAPS
LocalPort ✔     ✔     ✔     ✔     ✔     ✔    
QQ        ✔     ✔     ✔     ✘     ✔     ✘    
163       ✔     ✔     ✔     ✘     ✔     ✘    
Sohu      ✔     ✔     ✔     ✘     ✔     ✘    
Yandex    ✔     ✔     ✔     ✘     ✔     ✘    
Gmail     ✔     ✔     ✘     ✘     ✘     ✘    
Outlook   ✔     ✘     ✔     ✘     ✔     ✘    
Office365 ✔     ✘     ✔     ✘     ✔     ✘    
Yahoo     ✔     ✔     ✘     ✘     ✘     ✘    
MailCOM   ✔     ✔     ✔     ✘     ✔     ✘    
MailRU    ✔     ✔     ✘     ✘     ✔     ✘    
AOL       ✔     ✔     ✘     ✘     ✘     ✘    
GMX       ✔     ✔     ✔     ✘     ✔     ✘    
Sina      ✔     ✔     ✔     ✘     ✔     ✘    
Apple     ✘     ✘     ✘     ✘     ✘     ✘    
FastMail  ✘     ✔     ✘     ✘     ✘     ✘    
ProtonMail✘     ✘     ✘     ✘     ✘     ✘    
MXRoute   ✔     ✘     ✔     ✘     ✔     ✘    
Namecrane ✔     ✔     ✔     ✘     ✔     ✘    
XYAMail   ✘     ✘     ✘     ✘     ✘     ✘    
ZohoMail  ✘     ✔     ✘     ✘     ✘     ✘    
Inbox_eu  ✔     ✔     ✔     ✘     ✘     ✘    
Free_fr   ✘     ✔     ✔     ✘     ✔     ✘

机器性能

📌 转载信息

来源：
https://linux.do/t/topic/1429426

原作者：
STALK

转载时间：
2026/1/12 10:34:35

免费几乎无限的 17 级域名！

作者: 纯情
时间: 2026-01-11
分类: 网络
评论

参考：

省流：

去 https://tunnelbroker.net 创建隧道
解析 ipv6/64 地址，得到一个很丑的 *.ip6.arpa 域名
前往 dash.cloudflare.com ，添加域名，激活
回到 https://tunnelbroker.net ，查看隧道，找到下面的 rDNS，把 cf 提供的 Nameserver 填进去，一共两个，点 Save
片刻后，去 cf 手动触发一次激活验证，刷新几下
在 cf 复制 ZoneID、GlobalKey、你注册 cf 的邮箱地址，在终端执行 (出处)：

curl --location --request PATCH 'https://api.cloudflare.com/client/v4/zones/<你的区域ID>/ssl/universal/settings' \
--header 'X-Auth-Email: 你的CF注册邮箱' \
--header 'X-Auth-Key: 你的CF全局APIKey' \
--header 'Content-Type: application/json' \
--data-raw '{"enabled":true,"certificate_authority":"ssl_com"}'

更换 SSL 证书签发商（仅在 cf 有效）
7. 这样你就得到了一个很丑的 17 级域名
8. 关于 “无限” 的玩法：使用 he.net 获取近乎无限且永久的域名 - Lim's Blog

理论上讲，只要是支持 ipv6/64 rDNS 的都可以

玩玩即可，不要滥用，滥用会封号

The hostname is part of a banned domain. This web property cannot be added to Cloudflare at this time. If you are an Enterprise customer, please contact your Customer Success Manager. Otherwise, please email abusereply@cloudflare.com with the name of the web property and a detailed explanation of your association with this web property.

已经被 cf 拉黑了…

📌 转载信息

来源：
https://linux.do/t/topic/1427724

原作者：
Clancy

转载时间：
2026/1/11 08:30:56

D-NET 支持阿里云 ESA，实现 IPv6 免费加速方案（IPv4/IPv6 访问）

作者: 纯情
时间: 2025-12-28
分类: 网络
评论

家宽 IPv6 + 阿里云 ESA = 免费全球 IPv4/IPv6 加速！

痛点

家里搭了 All-in-One 服务器，拿到了运营商的公网 IPv6 ，但是：

外网访问 IPv6 太慢？仅支持 IPv6 客户端访问？
使用 Cloudflare CDN 访问速度较慢、延迟较高？
想用 CDN 加速但嫌贵？
域名未备案？
IPv6 地址老变化，手动更新太麻烦？

解决方案

D-NET + 阿里云 ESA ，完美解决上述问题：

传统方案： 家庭服务器 → DDNS 更新 DNS → 域名解析 → CDN 回源 → 访问（ 2 次解析）

D-NET 方案： 家庭服务器 → 监听 IPv6 地址变化直接更新 ESA → 访问（ 1 次解析，更快！）

性能实测

国内节点测试（备案域名）

D-NET 支持阿里云 ESA，实现 IPv6 免费加速方案（IPv4/IPv6 访问）1

全球节点测试（未备案域名）

D-NET 支持阿里云 ESA，实现 IPv6 免费加速方案（IPv4/IPv6 访问）2

实测数据：

海外访问延迟降低
国内访问（备案域名）几乎无感知
免费流量，不用担心收费问题

详细教程： https://aio.it927.com/remote/esa

GitHub： https://github.com/cxbdasheng/dnet （欢迎 Star ⭐）

完整 All-In-One 教程： https://aio.it927.com

适合你吗？

如果你有以下需求，强烈推荐试试：

✅ 家里有公网 IPv6
✅ 想要全球访问加速
✅ 不想花钱买 CDN
✅ 希望自动化管理

项目还在持续迭代中，欢迎提 Issue 和 PR ！
也欢迎分享你的使用场景和需求，一起让它更好用 🚀

📌 转载信息

来源：
https://www.v2ex.com/t/1181711

原作者：
cxbdasheng

转载时间：
2025/12/28 20:04:39