proxy-station/docs/FFSB-SURGE-AUDIT-2026-10-19.md

本机 FFSB / Surge / Claude Code 网络审计

审计日期：2026-10-19。只读采集和无凭据网络探测；本轮未修改生产数据、客户端配置、DNS、路由或开关，未重启服务。用户已明确不关闭增强模式，故未执行启动顺序切换实验。

范围与结论

以 FFSB 当前下发的 25 项域名规则为唯一业务边界，不要求缩减其中的查 IP 和 FFSB 网站；其余流量继续遵循 Surge。Claude Code 的官方业务流量属于 FFSB 范围，GitHub、npm、第三方 MCP 与工具目标继续按 Surge 规则。用户已说明会将 Claude Code 的 Base URL 恢复官方，本报告不展开现有本机 API 网关。

稳态下分流已基本成立；“所有启动顺序、断线与恢复阶段都只经 FFSB”尚未具备充分保障，不能宣称完成。 现有配置有可复现的另一条出口路径：将 Anthropic 请求显式交给 Surge，会匹配 AI 组并通过其远端代理；直接 DNS 查询也可能绕过 FFSB 分域解析而得到 fake-IP。

用户要求	证据与判定
FFSB 接管维护的 25 项	25/25 均有对应系统分域 DNS 范围；18 个精确域名中 16 个有地址且实际走 utun100、完成 HTTPS；2 个无 A 记录。通配规则不能靠根域探测宣称所有动态子域已验收
Claude Code 官方业务只走 FFSB	系统解析及本机独立 Bun 默认解析/HTTPS 路径成功；尚未恢复官方 Base URL 后进行真实 Claude Code 登录、模型生成或流式请求验收
Surge 保留其他分流，不将 FFSB 套进远端代理	FFSB 服务真实请求命中进程 DIRECT；GitHub 实际请求通过 Surge 原代理成功。但外层加密隧道仍由 Surge VIF 接管再 DIRECT 转发，并非完全绕过 Surge
启动顺序无关、断线不串线、长期稳定	两端自动启动/连接配置存在，但没有就绪协调或本次查验可确认的专属出口约束；没有进行双启动顺序、睡眠唤醒或长连接测试。当前不能保证

本机状态及配置来源

• Surge 6.10.0，活动配置 Proxy Station，rule 模式；增强模式开启，系统代理关闭。scutil --proxy 也未显示 HTTP/HTTPS 系统代理启用。
• Claude Code 2.1.292，通过 Homebrew 安装；本次主要证据采集时未发现正在运行的 Claude Code 主进程。独立 Bun 1.4.2 探测不等于已测试 Claude Code 内嵌运行时及实际认证业务。
• FFSB daemon 0.1.25；有效设置为 interfaceName=utun100、MTU 1280、disableAutoConnect=false、networkMonitor=true、disableDns=false、disableClientRoutes=false、disableIpv6=true。状态中的 lazy connection 与有效配置读数曾有差异，不将其作为就绪保证。
• FFSB 服务与 GUI、Surge 均有 enabled/allowed 的系统后台/登录项。FFSB launchd 配置 KeepAlive=true、RunAtLoad=false；不应只看后者便断言不自启，也不能由 KeepAlive 推出业务已就绪。
• 已检查用户及本项目 Claude 设置、常用 shell 配置和 launchctl 网络环境；过滤本次 Codex 会话注入变量后，新 fish/zsh 交互 shell 未发现显式 HTTP/HTTPS/ALL/NO_PROXY。不能将此推广为所有已打开终端、IDE、任意项目或后续进程环境。
• 生产 API 重读：272 条规则，FFSB 服务真实路径的进程例外、3 个服务器 IP 例外及 bootstrap 域名直连均在现有配置；本轮未增删。link.fufeishangban.com 在 always-real-ip 中。
• Tailscale 同时 Running；FFSB 的 100.70.0.0/16 落在 Tailscale 常用的 100.64.0.0/10 内。当前已知 Tailscale peer 未落入该 /16，因此未发现现有 peer 冲突；未来新增 peer/路由仍需检查。
• 当前 en0/en1 未发现全局 IPv6 地址，FFSB 禁用 IPv6，Surge ipv6=false、ipv6-vif=auto。这仅是当前网络状态，不能替代以后在有公网 IPv6 网络上的验收。

当前链路及其边界

使用系统解析器访问清单内可解析域名时：

应用 → macOS 分域 DNS → FFSB 本地 DNS 100.70.255.254
     → 按解析结果建立/使用 utun100 目标路由
     → FFSB 加密隧道 → 专线出口 → 目标服务

FFSB 加密隧道的外层连接
     → Surge utun5 → PROCESS-NAME /Applications/FFSB.app/Contents/MacOS/ffsb-service
     → DIRECT → 物理网络 → FFSB 服务器

清单外普通目标 → Surge DNS/utun5 → 原有规则与策略

DIRECT、系统代理绕过、VIF 路由排除是三件不同的事。当前 DIRECT 已证明避免 FFSB 外层走 Surge 远端节点，但 Surge 仍处理其包转发；所以不能说 Surge 完全不影响 FFSB。utun5 出现在外层服务器路由中，也不能单独证明隧道被远端代理。

macOS 的 resolver(5) 规定分域解析选择最长匹配后缀。系统查询正常时，FFSB 的 specific resolver 胜过 Surge 默认 DNS。NetBird 官方说明域名路由使用本地 DNS forwarder，并按查询结果增加目标路由；本机现象与之相符。但 FFSB 是定制客户端，不能把所有上游 NetBird 功能当作其已支持的功能。

证据：NetBird DNS、域名路由、DNS 排查、本机 man 5 resolver。

域名清单与实际检查

7 项通配规则：*.anthropic.com、*.clau.de、*.claude.com、*.claudemcpclient.com、*.claudemcpcontent.com、*.claudeusercontent.com、*.ffsb.sg。全部存在对应根域的系统分域 resolver。

以下为 18 个精确域名的无凭据 HTTPS 根路径探测。HTTP 403/404 只能证明 TLS/HTTP 可达，不代表登录、模型调用、内容权限或完整业务通过。

域名	解析/路由	HTTPS 状态
a.claude.ai	utun100	404
anthropic.com	utun100	301
api.anthropic.com	utun100	404
api.ipify.org	utun100	200
assets.claude.ai	utun100	403
clau.de	utun100	302
claude.ai	utun100	403
claude.com	utun100	200
claudemcpclient.com	无 A 地址	未执行 HTTPS
claudemcpcontent.com	无 A 地址	未执行 HTTPS
claudeusercontent.com	utun100	301
ffsb.sg	utun100	200
icanhazip.com	utun100	200
ifconfig.me	utun100	200
ip.net.coffee	utun100	200
join.fufeishangban.com	utun100	302
pivot.claude.ai	utun100	200
www.claude.ai	utun100	301

两个无地址 MCP 根域：FFSB DNS 返回 NXDOMAIN，公共 DNS 返回 NOERROR/空 A 回答。二者响应语义不同，不能声称 DNS 答案完全一致；但两边都无 A 地址，不能将根域 HTTPS 无法探测认定为隧道故障。仍需有效的动态子域样本验收，未通过猜测或采集用户会话内容来制造样本。

已另行核对 platform.claude.com、mcp-proxy.anthropic.com、bridge.claudeusercontent.com 的系统解析及路由，均为真实 IPv4/utun100，验证了相应通配域的一部分范围。

downloads.claude.ai 不在这 25 项内，实测为 fake-IP/utun5，符合 FFSB 客户端界面的安装包/更新例外。此处不扩展 FFSB 清单。域名相同 IP 时，系统 IP 路由可能一并覆盖该 IP 上的其他域名，因此这种模式并非逐 HTTP Host 的严格隔离。

已证实的旁路与尚缺的保障

1. DNS 路径不同会改变结果

同一时段、同一域名 api.anthropic.com：

• Python/system getaddrinfo、Node dns.lookup、独立 Bun 默认/system backend：真实 IP，目标路由 utun100。
• Node dns.resolve4、Bun c-ares backend：Surge 198.18.* fake-IP。
• 独立 Bun 默认 fetch 两次均完成 HTTPS，约 488/370 ms。

这不是断言当前 Claude Code 默认使用 c-ares；它说明现有分域接管依赖解析路径，不能凭规则列表保证所有调用方式。Node 与 Bun 官方文档明确区分系统解析器和直接 DNS 后端。浏览器 Secure DNS、显式代理和其他运行时也应分别验证。

参考：Node DNS、Bun DNS。

2. 显式代理可实际绕过 FFSB

本次只对单次无凭据 curl 请求指定已有 127.0.0.1:6152，未修改任何系统或应用代理配置。实际 Surge 请求 #51640 的 api.anthropic.com:443 命中 RULE-SET ai.conf，通过 AI 组的美国 Trojan 节点，完成 HTTP 请求。不是仅靠 rule match 推测。

因此，如果 Claude Code 后续继承 HTTP/HTTPS_PROXY，或其他客户端使用 Surge 系统/显式代理，当前配置允许清单内目标改走 Surge。新 shell 当前没有这些变量，并不构成禁止以后使用其他出口的机制。Claude Code 官方文档确认读取代理环境变量，并支持 NO_PROXY；既有进程不会随 shell 后续修改自动更新。

参考：Claude Code 网络配置。

3. 没有完整的启动/断线闭锁

自动启动不等于以下步骤已完成：管理连接、peer 握手、分域 DNS 注册、域名路由建立、真实 HTTPS 可用。FFSB 未就绪或退出时，Surge 的 AI 域名规则仍在；缺少 FFSB 路由/解析条件时，存在切换出口的配置路径。未实际关闭 FFSB 或 Surge 来验证该场景，不能将推断写成已实测断线结果。

本轮没有验证“Surge 先启动”和“FFSB 先启动”的完整矩阵，也没有运行 Claude Code 真实登录/流式业务、长时负载、网络切换或睡眠唤醒。此前反复出现超时后重新检测成功，根因没有被严格隔离；不能以成功重测认定已经永久修复。

4. 其他分流及服务自身流量正常

FFSB 服务真实请求的完整路径与生产进程规则一致，STUN 有响应；通过相同 STUN 目标、不同进程路径模拟，Chrome 仍为 REJECT。普通 GitHub 请求 #51650 命中 GitHub 规则集并通过 Surge 原代理，HTTP 200。Tailscale 的既有规则和本机选择未修改。

建议实施方向：不是继续扩大服务器网段

以下为待实施/待验收方案，不是本次已经部署的结果。

1. 保留已验证的 FFSB 服务进程 DIRECT、bootstrap 域名真实解析和已有服务器例外。服务器地址变化应主要由进程匹配覆盖，不靠放行宽网段。不要把 Claude Code 全进程设置为裸 DIRECT，这既不能强制使用 FFSB，还会改变清单外工具流量。
2. 以这 25 项维护单一清单，核对系统分域 DNS 与 Surge 内部 DNS 的一致性。若需要覆盖被 Surge 捕获的路径，候选做法是为该清单明确配置 FFSB DNS，并配合 always-real-ip；不把全局 DNS 改成 FFSB，不将 FFSB 控制服务器解析交回依赖自身隧道的 DNS。需验证解析失败时不自动落到公共 DNS。
3. 对已进入 Surge 的清单内请求，增加“只交给 FFSB 接口、不可回落”的策略，而非普通 DIRECT。例如官方支持 direct, interface=utun100, allow-other-interface=false。这是候选机制，未在本机启用或通过启动矩阵验证；必须先保证目标路由由 FFSB DNS 建立，核对接口实际存在及路由有效。仅靠这一项不保护 Surge 自身也未启动的阶段。
4. 若需求是“任何时刻都不可从别的出口发送”，还需要独立于应用启动顺序的约束：FFSB 未就绪则等待/拒绝，断开后停止新请求，并验证既有连接。启动前一次探测或普通脚本包装不能提供持续保障。应选择并验证本机持久流量限制或仅能通过 FFSB 出站的专用入口，而不是只依赖自动启动顺序。
5. 该类接口/DNS 绑定属于这台 Mac 的配置，应使用本机专用配置/模块，不能未经评估就向所有共享订阅设备下发 utun100 和该机的 FFSB DNS 地址。

Surge 官方依据：VIF 排除与系统代理、Host 首条匹配/分域 DNS、真实 IP 例外、指定接口与禁止其他接口回落。这些说明验证机制存在，不能代替本机端到端测试。

切勿向 tun-excluded-routes 机械添加 Claude 目标公网 IP 或整个 100.64.0.0/10：本项目已有物理网关排除覆盖 VPN 路由的实测教训，见 Surge/Tailscale 共存。FFSB 外层公网服务器和 FFSB 内层业务目标必须分开处理。

完整验收矩阵

场景	必须核对
Surge → FFSB → Claude Code	25 项 DNS/路由就绪，真实官方认证与模型请求走 FFSB；清单外仍按 Surge
FFSB → Surge → Claude Code	Surge 上线不改写/绕过已建立的 FFSB 业务路径；同上
Claude Code 先启动、FFSB 后上线	上线前等待或明确失败；不得先走 Surge/ISP，恢复后使用 FFSB
FFSB 断开或 daemon 崩溃	新请求不换出口；既有连接的行为有记录；恢复后的连接重新校验
Surge 重载托管配置/重启	本机覆盖仍存在，FFSB DNS/路由正常、控制与 STUN 不被拦截
睡眠唤醒、切换网络、有公网 IPv6	无 DNS/路由残留和其他出口回落，第三方流量仍正常
长时间 Claude 流式请求	不仅根路径 HTTP 成功；验证实际流、持续连接、重试和出口

证据保存与限制

敏感快照仅位于本机私有目录 /private/tmp/network-audit-20261019/，不提交 Git。这里仅记录脱敏结论及公开域名。运行时路由与 IP 可变化，后续实施前应重新采集。

本轮没有改网络，因此不存在本轮生产变更备份或“已部署修复”声明。先前进程路径修复与备份见 FFSB 直连记录。