proxy-station/docs/FFSB-MANUAL-SUBSCRIPTION-2026-10-19.md

# FFSB 手动选择与统一 Surge 订阅

本方案替代同日早先的 `Proxy Station Claude` 本机协调层。最终状态、验证结果见下文；旧实现文档保留为历史记录。

2026-11-02 本机后续已完成 [Surge 原生 WireGuard 独立验证](FFSB-WIREGUARD-SURGE-2026-11-02.md)，并于同日 11:05 按用户要求回退本文的正式 `Proxy Station`＋FFSB 组合，24/24 请求验收通过。原生 WG 试验配置与身份仅保留在本机私有归档，未改生产订阅。本文的 utun100／本机 DNS 前提描述组合方案，不代表原生 WG 必须运行 FFSB；两种方式复用同一身份，不可并行连接。

## 原理与前提

业务配置由正式订阅统一生成，本机仅使用 `Proxy Station`。可见的 `🦀 Claude` 为手动 select，原有国家和 AI Nodes 成员保持不变，新增 `🦁 FFSB`。不使用自动 fallback，不运行定时探测／配置重写脚本。FFSB 不可用时选中它应失败；用户自行改选 Surge 节点。

FFSB 0.1.25 的 Go 构建信息表明它基于 `github.com/netbirdio/netbird`，基线 `v0.75.1-0.20260920041446-3ee1e3889f9c+dirty`。依赖包括 WireGuard userspace 实现、Pion ICE/STUN/TURN、gRPC、QUIC。这证明其技术组成，不证明每种协议当前都在使用。实测状态中有 P2P 连接、host/srflx ICE 候选及 WireGuard 握手；本机使用 utun100，地址 100.70.160.98，本地 DNS 为 100.70.255.254。不能把它当成一个已有本地 SOCKS/HTTP 监听端口的普通代理。

原架构的问题是 FFSB 的系统分域 DNS 和真实 IP 主机路由可在 Surge 接管前接走流量。改动前，同一 api.ipify.org 请求，普通系统入口出口为 138.75.58.11，显式 Surge 入口为 179.253.249.56，即使 Claude 选择的是 Surge。单加一个选项不足以控制所有入口。

新的必要前提是本机 FFSB **持久设置 `disableDns=true`**，并重连一次使其生效。它停止修改系统 DNS，但仍提供内部 DNS 服务及客户端路由。只执行 up 修改设置而不重连，本机实测旧分域 resolver 仍存在；down/up 后才消失。没有关闭客户端路由，否则接口无法承接目标地址。

正常系统 DNS 由 Surge 增强模式返回 fake-IP，业务连接因此先进入 Surge；不为 25 项配置 always-real-ip。Surge 完成域名规则匹配后：

- 选 `🦁 FFSB`：direct 别名绑定 utun100，`allow-other-interface=false`；25 项的 Host 映射交给 100.70.255.254，`dns-follow-interface=true` 绑定查询接口。FFSB DNS 为域名资源解析并维护路由，随后连接走 WireGuard。
- 选国家或 AI Nodes：由远端代理解析目标域名，不依赖 FFSB DNS。即使 FFSB 已关闭，fake-IP 接管和远端解析仍可用。
- 25 项之外：所有原 Claude 分类规则（包括其 1.0.0.1 DoH 传输规则）转给隐藏 `Claude-Surge-Internal`，它只引用现有 `🧠 AI Nodes`。用户已明确要求这些地址始终走 Surge；这个内部组不能选择 FFSB。
- FFSB 外层：实际 daemon 进程的 DIRECT 规则在业务规则之前，避免再套远端代理。其他应用的 STUN 防护不删除。

因此，连接出口和 DNS 无需靠脚本同步切换；它依赖 Surge 的 fake-IP 与代理远端解析机制，以及 FFSB 的一次性客户端设置。不是“任意设备仅导入订阅、不配置客户端即可自动就绪”：其他 Mac 须确认接口/DNS 地址及 disableDns；iOS 共存、不同 FFSB 版本未验收。

## 官方依据

- [Surge direct 别名](https://manual.nssurge.com/policies/built-in.html)：允许在 Proxy 中声明带接口绑定的 direct 策略。
- [Surge 参数](https://manual.nssurge.com/policies/parameters.html)：接口须具备目标路由；不允许其他接口时不可用即失败；dns-follow-interface 只控制查询接口，不能等同于动态选择 DNS 服务器。
- [Surge DNS](https://manual.nssurge.com/dns/advanced.html)：fake-IP 将客户端连接还原为域名，再匹配出站策略。
- [本地与远端解析](https://kb.nssurge.com/surge-knowledge-base/technotes/dns)：代理请求默认交给远端解析。
- [Host 映射](https://manual.nssurge.com/dns/local-dns-mapping.html)：本地查询按首条映射选服务器；不是按组选项动态修改 Host。
- [隐藏策略组](https://manual.nssurge.com/policy-groups/parameters.html)：hidden=true 隐藏菜单中的内部组。
- [NetBird CLI](https://docs.netbird.io/get-started/cli)：disable-dns 停止配置系统 DNS；本机 FFSB help 也提供该参数。
- [NetBird 域名资源](https://docs.netbird.io/manage/networks/how-routing-peers-work)：本地 DNS 转发至路由节点，路由节点解析域名。FFSB 是修改版本，最终依据本机结果，不假定上游全部行为一致。

## 实现与部署

`server/src/services/generators/surge-ffsb.ts` 是 Surge 序列化适配，读取 IR 内生产 settings 的 `FFSB` 配置；不另行查库、不修改原 IR，也不影响 Clash/Shadowrocket。配置字段为 enabled、interface、dnsServer、extraPolicy。25 项唯一源为 `server/assets/ffsb-domains.json`；原 `rules/ffsb-domains.json` 为指向它的相对符号链接。

适配器保留原成员、只追加 🦁 FFSB；置顶精确 25 项规则，原合并范围继续隐藏分流；有名称冲突、无效接口或内部组循环依赖时拒绝生成。生产原有 14 组／277 规则不需要改写，适配规则由生成器下发。

生产写入前在线备份：`/opt/proxy-station/data/backups/before-manual-ffsb-selection-20261019-143021.db`。部署脚本会更改目录属主，因此部署完成后重新检查并恢复此备份 root:root、600。

本机已停用并移出 LaunchAgents 的 `com.proxystation.ffsb-overlay.plist`；`Default.conf` 和 `Proxy Station Claude.conf` 已移入私有归档，未删除。Surge 配置列表只保留 `Proxy Station`。归档位于 `~/Library/Application Support/ProxyStationFFSB/manual-migration-20261019-142442/`。

## 验证

迁移前两次可回滚试验已验证：

| 条件 | 普通系统入口 | 显式 Surge 入口 |
|---|---|---|
| FFSB 开启、DNS 接管关闭、选 FFSB | 138.75.58.11 | 138.75.58.11 |
| FFSB 开启、DNS 接管关闭、选 AI Nodes | 179.253.249.56 | 179.253.249.56 |
| FFSB 关闭、选 AI Nodes | 成功，179.253.249.56 | 成功，179.253.249.56 |
| FFSB 关闭、选 FFSB | 超时失败 | 超时失败 |

Surge 请求 #58762/#58763 显示两种入口绑定 utun100；#58765/#58766 显示两种入口经美国节点 en0。FFSB 关闭失败不自动改选，符合手动模式。

类型检查通过；全量 75 个测试通过、1 个原有用例跳过。新增 5 个测试验证精确范围、DNS/规则顺序、唯一可见组、IR 不变、其他客户端无变化、参数和循环保护、原生解析。正式候选与 HTTPS 产物均通过官方 CLI，49/49 规则集下载并通过快照校验。13 个域名遮蔽提示对应有意置顶的 25 项覆盖较宽 Claude 分类，保留集合外规则，不将它们扩进 FFSB。

最终正式订阅（🦁 FFSB 命名）已再次验证上述四种组合，并恢复至 FFSB 开启、🦀 Claude 选择 🦁 FFSB：

- 当前 FFSB CLI Selected 清单恰好 25 项，与源清单集合相等；25/25 原生规则解释都进入 🦁 FFSB（通配项用匹配样本验证规则，不等同于该样本有业务服务）。
- 18 个精确域名中 16 个完成 TLS/HTTP 传输；`claudemcpclient.com` 与 `claudemcpcontent.com` 请求 #59298/#59299 命中正确策略，但 FFSB DNS 返回空答案，未算连接通过。HTTP 403/404/426 只代表传输和根路径响应，不是登录或模型调用成功。
- 4 个真实通配样本 www.anthropic.com、platform.claude.com、bridge.claudeusercontent.com、c.ffsb.sg 完成传输；其余通配范围没有声称穷举验收。
- 官方 API #59292：🦁 FFSB、utun100。两种入口 #59287/#59289 均为 FFSB 出口。系统 lookup 返回 fake-IP 198.18.2.126，Surge DNS trace 则经 100.70.255.254 返回真实 160.79.104.10，说明应用接管与隧道解析分层生效。
- 集合外 #59315 downloads、#59316 Auth0、#59317 Datadog 均经隐藏策略走 Surge；#59318 GitHub 与 #59319 ChatGPT 保持各自 Proxy／AI 分流。
- 手动选美国、新加坡、日本，普通系统请求分别得到 179.253.249.56、54.254.42.195、104.28.243.105，全部成功；结束后恢复 🦁 FFSB。
- FFSB 外层 #59344 UDP/51820：DIRECT、en0，双向有字节；STUN 命中 DIRECT，未被全局 STUN 阻断。单条 STUN 样本无下行不据此声称该次 STUN 成功。
- 其他现有策略组选择与变更前一致，仅 🦀 Claude 改为 🦁 FFSB，新增隐藏内部组；FFSB 有效配置仅 disableDns 从 false 改为 true。系统代理仍关闭、增强模式仍开启，未重启 Surge 引擎。
- 最终 emoji 更新后的 HTTPS 订阅再次通过原生校验、49/49 规则集快照校验。一次规则集拉取失败后复测成功，不将失败结果当通过。

私有证据归档到 `~/Library/Application Support/ProxyStationFFSB/manual-migration-20261019-142442/evidence/`，含原生请求日志、DNS trace、四象限结果、生产前后快照和部署日志；文件权限 600、目录 700，不提交 Git。实际模型业务、启动顺序及长期场景未纳入本次完成声明。

## 边界与恢复

后续故障（同日约 14:46）：用户报告 GUI 检测失败，实际 curl 对 API、join、ipify 也超时。前台 `ffsb` 的检测请求命中业务策略 🦁 FFSB／utun100，但只有上行；后台 `ffsb-service` 的控制、WireGuard 和 STUN 仍命中 DIRECT／en0。直接指定真实 IP 并绑定 utun100 的请求同样失败；Go 默认 TLS 与经典曲线对照均超时，不支持仅为大 TLS 握手问题的假设。绕过的是内层业务接管，外层 UDP 仍经 Surge，因此尚未定位是 FFSB 状态、远端还是外层转发问题。管理/信令 Connected 不等于业务可用，早先验收仅代表当时状态。此次未修改配置或重连，证据归档于上述私有迁移目录的 `failure-followup-1446/`。

### 追加故障排查：新连接 TLS 间歇性停顿

同日继续排查，**尚未完成根因修复**。不能把前述迁移验收或暂时恢复视为稳定性通过。服务为第三方运营，用户确认没有服务端权限。

| 对照 | 实测结果与结论边界 |
|---|---|
| 外层进程与业务进程 | `ffsb-service` 的管理连接、WireGuard UDP/51820 命中 DIRECT/en0；前台 `ffsb` 的官方地址检测命中 🦁 FFSB/utun100，属于预期内层流量，不是仅凭策略名称就能判定的回环 |
| 仅排除两台外层服务器的 TUN 路由 | 临时排除 185.180.19.201/32、147.93.172.146/32；实际路由为 en0，重连后 3 个 HTTPS 目标仍超时；已恢复正式配置，没有保留排除项 |
| 系统 DNS 管理开关 | 临时启用再关闭并重连曾恢复；随后的同条件对照不能复现，之后再次失败；故不能归因为 disableDns 或 DNS 缓存 |
| 故障时直接查询 FFSB DNS | 可返回真实地址，随后 TLS 仍失败；单纯刷新 DNS 不能修复 |
| 绕过 Surge 内层接管 | curl 指定真实目标 IP 并绑定 utun100，同样失败；这不代表绕过了外层 Surge 转发 |
| TCP 抓包 | 15:00:08 的 API 新连接完成 SYN/SYN-ACK/ACK，327 字节 ClientHello 获对端 ACK，此后未收到 TLS 响应；同时其他既有 API 连接仍收发数据。未解密 TLS，也未调用计费模型 API |
| MTU 对照 | utun100 从 1280 临时降为 1200，新 SYN 的 MSS 从 1240 降到 1160，HTTPS 仍失败；已恢复 1280，未持久修改 MTU |
| TLS 实现与版本 | Go 默认/经典曲线和 curl 均出现超时；TLS 1.2 也失败。不能认定仅为 Go 的后量子 ClientHello 大小问题 |
| HTTP/HTTPS 对照 | 同一阶段 HTTP 曾成功，而 API、ipify、assets、pivot、ifconfig 多个 HTTPS 超时；HTTP 随后也有超时，不能断言故障严格只限 HTTPS |
| 延长一次观测超时 | API 最终 18.53 秒完成 TLS、18.72 秒收到 HTTP 404，超过 GUI 的 10 秒预算；这是延迟证据，不是修复，也未修改客户端检测超时 |
| TCP ECN | 仅测试 socket 上分别默认、关闭和开启 ECN，后来均成功；随后原 Go 测试也自行恢复，不能据此更改全机 ECN 设置 |

本机证据将问题收窄到 FFSB 数据路径的新连接/TLS 响应阶段；尚不能进一步区分客户端实现、外层传输、路由节点转发或其上游。需要服务商在 `b5-primary.ffsb.internal`（100.70.254.2，对外 185.180.19.201:51820）侧关联同一时间的抓包与转发日志。TCP ACK 可能由中间转发组件生成，不能仅凭它认定最终官方服务器已收到 ClientHello。[NetBird 官方排障](https://docs.netbird.io/help/troubleshooting-resource-connectivity)同样要求把 peer 连通、资源 TCP 连接及应用响应分层检查。

恢复后的最后观测窗口为 15:07:54—15:09:42（UTC+8）：6 轮 × 4 路径共 24/24 完成 HTTP 响应，其中 FFSB 系统入口、显式 Surge 入口、真实 IP 绑定接口各 6 次，GitHub 普通 Surge 对照 6 次。官方 API 的 404 仅证明传输成功。原生请求 #61197 为 API → 🦁 FFSB/utun100，#61196 为 ipify → 🦁 FFSB/utun100，#61198 为 GitHub → US LA VMess Direct/en0。此窗口不足两分钟，不构成长时间稳定性验收；故障窗口中的失败没有被后续成功覆盖。全部原始证据归档到上述迁移目录的 `failure-followup-1510/`，附 SHA-256 清单。

本轮不重启 Surge、不关闭增强模式、不改生产规则；临时 profile、路由排除、系统 DNS 试验与 MTU 都已恢复。最终 FFSB resolved config 与排查前逐字段一致，旧协调 LaunchAgent 未加载。抓包进程已停止。原始日志和诊断包只留本地，不上传第三方。GUI 自动化工具不可用，最后的界面检测状态未重新验收。

本机普通域名客户端和显式代理入口是验收范围。硬编码真实 IP、私有 DoH、先前缓存的真实地址或旧长连接可能绕过 fake-IP，选择不会迁移旧连接；必要时重新建立应用连接。未对真实计费模型流、全部通配子域、长期运行、睡眠换网、IPv6 数据路径或其他设备宣称验收完成。

恢复旧客户端 DNS 管理需 `ffsb-service down` 后 `ffsb-service up --disable-dns=false`，不能仅改配置就断言生效。恢复生产功能开关通过管理 API 将 FFSB.enabled 改为 false 并更新订阅；不能只恢复系统 DNS、却误以为仍有统一手动入口。旧脚本和配置仅用于调查／回滚，不重新自动启用。