[{"content":"","date":"2026年6月8日","externalUrl":null,"permalink":"/posts/","section":"Posts","summary":"","title":"Posts","type":"posts"},{"content":"最近在给 sing-box 配置双栈（IPv4 + IPv6），折腾过程中踩了两个坑，记录一下。\n坑一：DNS 策略藏着 ipv4_only # 一开始怎么配 IPv6 都不走，排查了一圈，最后发现是 DNS 配置里有个 \u0026quot;strategy\u0026quot;: \u0026quot;ipv4_only\u0026quot; 在作祟。它让 sing-box 直接丢弃所有 AAAA 记录，IPv6 根本无从谈起。删掉或改成 prefer_ipv6 就好了。小坑。\n坑二：链式代理下 IPv6 大包莫名卡死 # 真正的噩梦是这个。网络拓扑：\n客户端 Mihomo (SOCKS5) → 公网高速中转节点 → 服务器 Nginx (Stream) → sing-box (AnyTLS) → 目标\n双栈配好后，访问 test-ipv6.com 出现了非常分裂的现象：\nIPv6 地址检测 ✅ 小包连通性 10/10 ✅ 大数据包传输测试 ❌ 进度条卡死，最终超时 具体表现是：网页能打开，但只要涉及大图、视频流、文件上传，就直接挂起。DNS 解析正常、TLS 握手成功，但数据一多就断流。\n排障过程 # 我怀疑过中转节点配置不对、Nginx stream 转发有问题、sing-box 参数没调好，甚至换用了 anytls-go 标准实现测试——全部失败。\n当时还想过一个方向：是不是链式代理里某段链路的 MTU 有问题？但转念一想，链式代理已经把原始请求包层层封装了，中间代理段传输的是封装后的隧道流量，中间环节根本不需要关心什么 MTU——要管也是管物理链路的 MTU。\n所以问题只可能出现在两个端点：客户端出站，或服务器出站。\n最后直接在服务器上 curl 那个大数据包测试 URL，发现服务器自己都请求超时。说明问题不在代理软件，而是服务器网络层自身就在丢包。\n决定性证据 # test-ipv6.com 的大数据包测试本质上是这个请求（注意用引号包裹，否则 shell 会错误解析 \u0026amp; 和 ?）：\ncurl -6 \u0026#34;https://mtu1280.osaka.test-ipv6.com/ip/?callback=?\u0026amp;size=1600\u0026amp;fill=xxxxxxxx...\u0026amp;testdomain=test-ipv6.com\u0026amp;testname=test_v6mtu\u0026#34; 它会发送 1600 字节的填充数据。如果 MTU 正常，响应是一个 JSONP callback 返回你的 IPv6 地址。如果卡死或超时，说明路径上存在 MTU 黑洞。\n根因：机房 MTU 非标配置 # 用 ping -M do -s 逐级探测，找到了精确的边界：\nping -M do -s 1232 ipv6.google.com # 通 ping -M do -s 1233 ipv6.google.com # 断 计算：1232 (payload) + 8 (ICMPv6 头) + 40 (IPv6 头) = 1280。\n结论：机房链路的 IPv6 MTU 被硬限制在了 1280 字节。 上游设备配置了非标准的 MTU，且 ICMPv6 Type 2 (Packet Too Big) 要么根本没发，要么发了也被中间代理层当垃圾丢了。路径 MTU 发现（PMTUD）在这里完全是个摆设。\n既然机房不守规矩——不发 ICMPv6 No.2，那我也没必要跟它搞什么协议协商。不依赖 PMTUD，不依赖客户端配合，直接在服务器物理层把规矩立死：我就是这么发包的，超过 1280 的一个不放。\n解决方案：路由级 MTU 隔离 # 目标是 IPv4 和 IPv6 在同一张网卡上走不同的 MTU——IPv4 满载 1500，IPv6 限制 1280。\n走弯路：改网卡 MTU # 一开始直接 sudo ip link set dev eth0 mtu 1280，测试通过了，但 IPv4 流量也被迫降到 1280，白白损失性能。\n最终方案：ip -6 route change # 用 ip -6 route change 修改 RA 下发的默认路由，仅对 IPv6 路径限 MTU：\n# 1. 恢复 eth0 到 1500 sudo ip link set dev eth0 mtu 1500 # 2. 查看当前 IPv6 默认路由（RA 自动下发） ip -6 route show default # 输出：default via fe80::464c:a8ff:fe08:f27f dev eth0 metric 100 mtu 1500 # 3. 修改默认路由，强制 IPv6 MTU=1280 sudo ip -6 route change default via fe80::464c:a8ff:fe08:f27f dev eth0 mtu 1280 metric 100 # 4. 如有备用路由也一并修改 sudo ip -6 route change default via fe80::464c:a8ff:fe08:f27f dev eth0 metric 1024 mtu 1280 验证：\nip -6 route show default # default via fe80::... dev eth0 metric 100 mtu 1280 ✅ ip link show eth0 | grep mtu # mtu 1500 ✅ IPv4 不受影响 原理：Linux 路由表项的 MTU 优先级高于接口 MTU。IPv4 查路由表走接口默认 1500，IPv6 查路由表命中 mtu 1280 条目，内核自动分片——同一张网卡，两种标准，互不干扰。\n由于路由通过 RA 获取，重启后会被重置。如需持久化，写入 netplan：\n# /etc/netplan/99-ipv6-mtu.yaml network: version: 2 renderer: networkd ethernets: eth0: mtu: 1500 dhcp4: true dhcp6: true routes: - to: ::/0 via: \u0026#34;fe80::464c:a8ff:fe08:f27f\u0026#34; # 替换为你的网关 on-link: true mtu: 1280 sudo netplan apply 再踩一坑：RA 每 1800 秒重置路由 # 配完消停了一会儿，又不好使了。ip -6 route 一看：\ndefault via fe80::464c:a8ff:fe08:f27f dev eth0 proto ra metric 100 mtu 1500 default via fe80::464c:a8ff:fe08:f27f dev eth0 proto static metric 1024 onlink mtu 1280 RA 下发的路由 metric 100 优先级高于我手动加的 metric 1024。 内核永远选 metric 小的那条，流量还是走 1500 MTU，大包继续丢。\nRA (Router Advertisement) 默认每 1800 秒刷新一次，每次刷新都会覆盖我的改动。\n解法：netplan 指定 metric # 踩了个坑后发现：netplan apply 本身会触发 RA 刷新，所以直接在 netplan 的 routes 里显式指定 metric: 1 即可，RA 那条是 metric 100，我们的优先级永远更高：\n# /etc/netplan/99-ipv6-mtu.yaml network: version: 2 renderer: networkd ethernets: eth0: mtu: 1500 dhcp4: true dhcp6: true routes: - to: ::/0 via: \u0026#34;fe80::464c:a8ff:fe08:f27f\u0026#34; # 替换为你的网关 on-link: true metric: 1 mtu: 1280 sudo netplan apply 不需要 cron 守护脚本了，netplan 一次性搞定。\n总结 # 双栈配了不走 IPv6 → 先检查 DNS strategy 是不是 ipv4_only IPv6 小包通、大包卡 → 不要急着调代理软件，先在服务器上直接测。用 ping -M do -s 找到 MTU 边界，再用 ip -6 route change 做路由级隔离，让 IPv4 和 IPv6 走不同的 MTU 机房网络的非标 MTU 配置很常见，IPv6 的 PMTUD 又脆弱，学会在路由层面做策略控制是实用技能 ","date":"2026年6月8日","externalUrl":null,"permalink":"/posts/singbox_dualstack/","section":"Posts","summary":"","title":"Singbox 双栈配置：两个坑","type":"posts"},{"content":"","date":"2026年6月8日","externalUrl":null,"permalink":"/","section":"soloopooo的小窝-重置版","summary":"","title":"soloopooo的小窝-重置版","type":"page"},{"content":" 前言 # 相信很多人都听过“上古时期”拨号连接时的“猫叫”。当时人们还在使用电话线上网，速率最高只有57.6Kbps。“多图杀猫”这一俚语也是从那一时期生成出来。\n前些日子在网上冲浪时，看到 b 站某些 up 主使用了电话交换机和实体调制解调器（猫），让 Windows 11 实现了拨号上网，甚至实现了双机互联和超级终端功能。当时我在构思，有没有一种可能，不使用物理硬件，只使用软件模拟这些功能实现双机互联和拨号上网呢？\n还真让我发现了这样一个开源软件：atduck\natduck 模拟了一个 Hayes 兼容的调制解调器。\n部署 atduck # 2019 年有一篇博客详细记录了使用atduck进行拨号上网的步骤。\nATduck 本身安装简单，但是它依赖 Perl 的 IO-Pty 模块，以及 Slirp 软件。Slirp 可以在一个 TTY 上模拟一个 SLIP 或者 PPP 协议的服务端，ATduck 本身只实现了 Modem 的部分，联网部分都交由 Slirp。\n但是由于显而易见的原因，Slirp 已经很少用到了。Arch Linux 的软件源里根本没有，甚至连 AUR 里都没有。根据 Wikipedia 的 Slirp 页面显示，Slirp 的部分维护交由 Debian 维护者进行。\n里面有他使用的Dockerfile:\nRUN PKG_INSTALL(git slirp perl libio-pty-perl tini) \\ \u0026amp;\u0026amp; git clone https://github.com/nandhp/atduck.git \\ \u0026amp;\u0026amp; ln -sf /usr/bin/slirp /atduck/slirp-nandhp-patch \\ \u0026amp;\u0026amp; PKG_UNINSTALL(git) \\ \u0026amp;\u0026amp; FINAL_CLEANUP() WORKDIR /atduck ENTRYPOINT [\u0026#34;tini\u0026#34;, \u0026#34;/atduck/atduck\u0026#34;, \u0026#34;--\u0026#34;, \u0026#34;-l\u0026#34;, \u0026#34;0.0.0.0:5555\u0026#34;] 或者直接使用他的镜像：xddxdd/atduck\n如果你使用 Virtualbox, 那你就可以直接参照博客说明添加串口并使用了。\n但是针对 VMware 虚拟机而言，这个 Dockerfile 是不能使用的：一方面，它指定 atduck 监听在 TCP 端口上，而 VMware 只支持使用 Unix Socket 通信串口。所以我们需要稍微修改一下：\n方式一：直接修改现有镜像启动命令\nFROM xddxdd/atduck ENTRYPOINT [\u0026#34;tini\u0026#34;,\u0026#34;/atduck/atduck\u0026#34;,\u0026#34;--\u0026#34;,\u0026#34;-l\u0026#34;,\u0026#34;/tmp/modem\u0026#34;] 方式二：直接将DockerFile里的ENTRYPOINT修改为ENTRYPOINT [\u0026quot;tini\u0026quot;,\u0026quot;/atduck/atduck\u0026quot;,\u0026quot;--\u0026quot;,\u0026quot;-l\u0026quot;,\u0026quot;/tmp/modem\u0026quot;]。\nRUN PKG_INSTALL(git slirp perl libio-pty-perl tini) \\ \u0026amp;\u0026amp; git clone https://github.com/nandhp/atduck.git \\ \u0026amp;\u0026amp; ln -sf /usr/bin/slirp /atduck/slirp-nandhp-patch \\ \u0026amp;\u0026amp; PKG_UNINSTALL(git) \\ \u0026amp;\u0026amp; FINAL_CLEANUP() WORKDIR /atduck ENTRYPOINT [\u0026#34;tini\u0026#34;,\u0026#34;/atduck/atduck\u0026#34;,\u0026#34;--\u0026#34;,\u0026#34;-l\u0026#34;,\u0026#34;/tmp/modem\u0026#34;] 然后编译即可运行。\ndocker build -t atduck1 . 可以直接使用 docker compose:\nservices: atduck: image: atduck1 # 改成你自己编译的镜像名称 container_name: atduck restart: always volumes: - /tmp:/tmp # 如果你使用的是如我所示的 Unix Socket 就加上。否则如原博客所示，加端口监听即可 实现拨号上网 # 我们这里使用 VMware。\n依照上一节中 ENTRYPOINT 的指令标识，我们在/tmp/modem的位置创建了一个 Unix Socket。\n不过首先，需要设置一下它的权限，且每次启动 atduck docker 时都要设置，不然身为普通用户权限的 VMware 无法读写该 Socket，会报权限不足。\n注意！ 如果你不是首次启动 atduck 容器, 请务必先删除 /tmp/modem 后再启动，否则可能会出现无法监听的问题。\nsudo rm /tmp/modem # 这两条指令必须在启动容器之后执行，username是你的用户名 sudo chown username /tmp/modem sudo chgrp username /tmp/modem 然后，在我们需要拨号上网的虚拟机设置中添加一个串口设备：\n添加串口设备 按图中设置，选择使用 socket(named pipe)，并设置 From Client to An Application。\n设置串口 启动虚拟机，在“控制面板-\u0026gt;打印机和其他硬件-\u0026gt;电话和调制解调器选项”中安装调制解调器（ Windows XP 下可以直接安装标准 56000bps 调制解调器，Windows 2000 下需要安装 Hayes 的调制解调器）\n安装好了的调制解调器 添加一个新的拨号连接，使用新建连接向导：\n选择 连接到 Internet 选择 手动设置我的连接 选择 用拨号调制解调器连接 输入连接名，随意输入，这个名字就是你的连接名字 输入电话号码：5555 参照这里 留空用户名和密码，无需输入 你可以选择添加一个快捷方式 然后就创建完毕了，可以进行连接了，享受网上冲浪吧少年！\n连接成功 选什么电话号码？ # 按照 atduck 使用说明的 DIALING PLAN:\nThe following dialing plan is configured by default.\n5550 Connect to a shell on the host\n5555 SLiRP (PPP mode)\n5556 SLiRP (SLIP mode)\n6xxx Call another emulated modem by serial number. For example, dialing 6006 will connect you to the modem with serial number 6. To determine your modem\u0026rsquo;s serial number use AT+GSN. Note that serial numbers are not fixed between sessions.\n我们可以得知，如果想实现拨号上网，需要虚拟机拨 5555 或 5556，我们选择 Windows 默认使用的 PPP 模式，即5555。\n实现双机互联 # 注意！ 在进行接下来的操作前，请断开你的拨号连接，因为会“占线”。 既然拨号连接都成功了，那自然需要体验一下和朋友煲电话粥传送“大文件”的快乐了～\n我们需要用到超级终端，Windows 3.1 到 Windows XP 下的原版镜像都有这个东西，一般在附件-通讯中可以找到。\n我们使用一台 Windows 2000 的虚拟机和我们的 Windows XP 进行互联。\n我们需要让一个 atduck 实例同时监听两个 Unix Socket ，可以修改ENTRYPOINT如下：\nENTRYPOINT [\u0026#34;tini\u0026#34;,\u0026#34;/atduck/atduck\u0026#34;,\u0026#34;--\u0026#34;,\u0026#34;-l\u0026#34;,\u0026#34;/tmp/modem\u0026#34;,\u0026#34;-l\u0026#34;,\u0026#34;/tmp/modem2k\u0026#34;] /tmp/modem2k 就是我们 Windows 2000 虚拟机将要使用的 Socket。\n新开一个终端，依然像我们上面所说的，处理好权限问题。\n打开 Windows 2000 虚拟机，安装好调制解调器。\n根据选什么电话号码：\n6xxx Call another emulated modem by serial number. For example, dialing 6006 will connect you to the modem with serial number 6. To determine your modem\u0026rsquo;s serial number use AT+GSN. Note that serial numbers are not fixed between sessions.\n我们知道如果想要双机互联，需要拨6xxx。那么到底该拨多少呢？\n我们需要 putty 直接进行串口通信，去网上下载 putty 0.61 版本，可以在 Windows 2000 和 Windows XP 上运行。\n打开 putty，选择连接 Serial 连接到COM1\n点击连接，输入AT+GSN：\n提示！ 如果你使用docker logs -f atduck查看就可以看到 atduck 的AT指令日志，可以实时查看你的交互。\n使用AT指令查看序号 看到图中回复2， 说明该电脑的电话号码是6002。\n我们打开超级终端，等候拨入：\n等候呼叫 打开 Windows 2000, 拨 6002，注意不要带区号：\n注意！ 图里的调制解调器是错的，需要安装使用 Hayes 兼容的调制解调器，Windows 2000 可以选择 标准56000 V90。 呼叫 然后\u0026hellip;就连上了\n双机互联 使用传送功能发个“大文件”吧：\n煲电话粥传文件\u0026hellip; 最后 # 这个程序还可以玩更多的东西，但我没怎么试过，所以我也只能写这么多了。\n","date":"2026年1月4日","externalUrl":null,"permalink":"/posts/using_atduck/","section":"Posts","summary":"","title":"使用 atduck 模拟拨号上网及双机互联","type":"posts"},{"content":"本 blog 目前已经使用双 Pages 同步部署。详见 Cloudflare Pages, Github Pages\n由于众所周知的原因，Cloudflare Pages 的访问速度是可以比 Github Pages 更快的，原因在于 Cloudflare 的全球（除某大国外） CDN 网络。\n得益于 Cloudflare 仪表板内的 Pages 功能，我们可以很方便地对现有的仓库进行部署。\n本 blog 的原始仓库位于这里：\n发布至Github Pages和Cloudflare Pages的过程非常简单：\n得益于强大又免费的 Github Actions, 使用官方 Actions 即可构建到 Github Pages 环境。相似地，使用 Cloudflare 也可以进行自动构建，并在 git 仓库更新时自动重新构建并自动上传至 Cloudflare 全球网络。\nCloudflare Pages 构建页面 读者可以根据自己静态页面的构建环境自行编写 Workflows ，编写完成后自动构建并发布到 Pages。\n注意！ 请保证 Github Pages 和 Cloudflare Pages 的自定义域名不同。 注意！ 由于 Cloudflare Pages 默认使用的顶级域名 pages.dev 被 SNI 阻断，请务必添加一个自定义域名。 ","date":"2025年12月22日","externalUrl":null,"permalink":"/posts/gpages_and_cfpages/","section":"Posts","summary":"","title":"同时使用Github Pages和Cloudflare Pages部署静态网页","type":"posts"},{"content":" 我重生了\u0026hellip; # 由于之前blog的内容丢失，于是我重生了\u0026hellip;\n使用 Hugo \u0026amp; blowfish 驱动。\n加入了多语言支持，源语言是中文，翻译可能由我或者 AI 代劳。\n","date":"2025年12月21日","externalUrl":null,"permalink":"/posts/rel/","section":"Posts","summary":"","title":"我重生了...","type":"posts"},{"content":"","date":"2025年12月21日","externalUrl":null,"permalink":"/links/","section":"Links","summary":"","title":"Links","type":"links"},{"content":"这些是一些大佬们的链接：\n心水湛清 # # Kamipoi # # Trave11er aka Maxizero # # ","date":"2025年12月21日","externalUrl":null,"permalink":"/links/links/","section":"Links","summary":"","title":"Links","type":"links"},{"content":"","externalUrl":null,"permalink":"/authors/","section":"Authors","summary":"","title":"Authors","type":"authors"},{"content":"","externalUrl":null,"permalink":"/categories/","section":"Categories","summary":"","title":"Categories","type":"categories"},{"content":"","externalUrl":null,"permalink":"/series/","section":"Series","summary":"","title":"Series","type":"series"},{"content":"","externalUrl":null,"permalink":"/tags/","section":"Tags","summary":"","title":"Tags","type":"tags"}]