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

# FFSB / Surge 稳态分流设计与部署验收

> 后续状态：用户新增关闭回退要求后已实施新的本机协调层。本文为早期无回退方案，不代表当前配置；当前结果与未覆盖项见 [实施及验收](FFSB-SURGE-IMPLEMENTATION-2026-10-19.md)。

## 目标与设计状态

以 FFSB 实际维护的 25 项域名为集合 D。两个客户端已启动、就绪并连接后：D 内业务的 DNS 交给 FFSB，业务经 FFSB；D 外按 Surge 原规则；FFSB 的外层控制/隧道/STUN 连接不使用任何远端代理。用户不要求未就绪时可用，因此不引入开机串行调度器。

这是设计，不是已部署配置。本轮只完成官方资料核对、FFSB DNS 只读探测和 Surge 离线语法验证。现状证据见 [审计报告](FFSB-SURGE-AUDIT-2026-10-19.md)。

可验证目标是“出口确定、解析一致、入口不依赖进程名称”。无法承诺远端服务器、运营商和客户端软件永不故障。异常时明确失败比悄悄换出口更符合该目标。

## 第一性原理与约束

1. IP 路由看目标 IP，不看域名或 Claude 品牌。要按 D 分流，必须在 DNS、HTTP CONNECT 或其他仍能看到目标域名的入口完成分类。
2. FFSB 的域名网络不仅回答 DNS，还参与建立对应 IP 的隧道路由。使用它的 DNS，才能让解析结果和路由状态保持一致；不能长期写死公网业务 IP。
3. 应用经 macOS 系统 resolver 时，可以由 FFSB 分域 DNS 与更具体的 utun100 路由接管。显式使用 Surge 代理时，连接先到 Surge，由 Surge 重新解析/建立连接；必须为这个入口另行指定同一个最终出口。
4. Surge 增强模式下的普通 DIRECT 不是“送入另一个 VPN”的承诺。官方给出的共存机制是 direct 类型策略绑定 VPN 接口，并要求该接口存在有效目标路由。
5. FFSB 的外层 UDP/控制连接与其承载的业务是两层不同的流量。外层必须走物理网络，不能再次送回 FFSB，否则构成环路。

依据：[Surge 的 VPN 共存原理](https://manual.nssurge.com/book/understanding-surge/en/)、[接口绑定参数](https://manual.nssurge.com/policies/parameters.html)、[NetBird 域名路由机制](https://docs.netbird.io/manage/networks/how-routing-peers-work)。FFSB 是定制版本，其实际行为仍以本机测试为准。

## 推荐架构：多个入口，同一最终出口

```text
本机应用访问 D
  ├─ 系统 DNS → FFSB DNS → 真实 IP / utun100 → FFSB
  └─ Surge DNS、VIF 或本地显式代理
        → D 的 DNS 指向 FFSB
        → FFSB-Only 策略绑定 utun100 → FFSB

FFSB 外层服务进程 → Surge DIRECT（如被接管）→ 物理网络 → FFSB 服务器

本机应用访问 D 外目标 → Surge 原 DNS、规则与策略
```

这里“由 FFSB 接管”指业务出口归 FFSB，不要求每个本地字节永远不经过 Surge。请求已经发给 Surge 的 HTTP 代理端口时，Surge 必须参与接收；它应只把这类请求交给 FFSB，而非自己的远端节点。

### A. 单一域名清单

以 FFSB 的 25 项生成业务规则、Host DNS 映射和 always-real-ip 列表，不独立维护三份手工清单。原集合包含 18 个精确域名、7 个通配域。

- 精确域名用 DOMAIN；通配域按原含义用 DOMAIN-WILDCARD。
- 不把精确 `claude.ai` 扩成 `*.claude.ai`；`downloads.claude.ai` 仍是集合外的下载例外。
- 根域和 `*.根域` 分别保留；Surge Host 通配符不会自动包含根域。
- FFSB 清单更新后做差异检查和重新验收；不因看到新服务器 IP 就扩大公网网段。

### B. DNS 归属

保留 FFSB 的系统分域 DNS。对 Surge 内部 DNS，同一个 D 集合在 Host 中指定 `100.70.255.254`，其优先级高于 AI 公共 DoH 映射；D 加入 always-real-ip。示意：

```ini
[Host]
api.anthropic.com = server:100.70.255.254
*.anthropic.com = server:100.70.255.254
# 实际实现由 D 生成全部映射
```

这使直接问 Surge DNS 的客户端也应获得 FFSB 的真实回答，而不是依赖 fake-IP 或公共 DoH。集合外 DNS 保持原有行为。D 的 DNS 不配置公共解析器作为备用，以免 FFSB 故障时解析/路由悄悄换路。

FFSB 控制入口 `link.fufeishangban.com` 不放入依赖自身隧道的 DNS 路径；其 bootstrap 继续使用可独立工作的普通 DNS，并返回真实 IP。

**必须验证 Surge 内部 DNS 确实能到达 FFSB DNS。** `dns-follow-interface` 对连接解析有效，但官方注明“规则匹配阶段触发的 DNS”不保证指定接口，因此不能只靠该参数推断全部 DNS 路径成功。若 Surge DNS 阶段的访问验证失败，此设计尚未通过部署验收，不使用公共 DNS 兜底掩盖问题。

依据：[Host 映射及首条匹配](https://manual.nssurge.com/dns/local-dns-mapping.html)、[always-real-ip](https://manual.nssurge.com/dns/advanced.html)、[dns-follow-interface 的范围](https://manual.nssurge.com/policies/parameters.html)。

### C. 业务出口绑定

对已经进入 Surge 的 D 请求使用专用策略：

```ini
[Proxy]
FFSB-Only = direct, interface=utun100, allow-other-interface=false, dns-follow-interface=true

[Rule]
DOMAIN,api.anthropic.com,FFSB-Only
DOMAIN-WILDCARD,*.anthropic.com,FFSB-Only
# 实际实现由 D 生成全部业务规则
```

- 指定 FFSB 有效配置中的接口，不依赖 Surge 的 utun 编号。
- 不使用 fallback/url-test 让 D 落回普通代理或物理 DIRECT。
- 必须在 FFSB DNS 返回后核对该 IP 在 utun100 上有有效路由；仅设置接口并不能创造路由。
- 未就绪时允许明确失败，符合最新需求；此方案不声称保护所有客户端均未启动的阶段。

### D. 外层传输与规则顺序

FFSB 服务的真实可执行路径放在业务规则之前，走普通 DIRECT：

```ini
PROCESS-NAME,/Applications/FFSB.app/Contents/MacOS/ffsb-service,DIRECT
```

不能误用 `/usr/local/bin/ffsb-service` 符号链接路径；不能豁免所有 Claude 应用或整个 FFSB GUI bundle，否则可能把 GUI 的业务检测也送去物理网络。

最终相关优先级：FFSB 外层进程例外 → D 业务专用策略 → 其他现有规则。FFSB bootstrap 和必需 DNS 的明确规则按依赖关系放在通用 IP/STUN 规则之前。外层 STUN 不被全局 STUN REJECT 截获，其他进程的 STUN 仍遵循原策略。

其他规则按原意保留；“从原理设计”不等于重置生产规则。该机接口绑定属于本机配置，不传播到所有共享订阅设备。

### E. 应用与 DNS 的可识别性

“任何进程”可做到不按应用名单分流，但不能包含任意绕过本机网络控制的隧道。方案的可执行前提是：

- 浏览器使用系统 DNS，不另走自行配置的 Secure DNS/DoH 或独立 VPN/Private Relay。
- 应用不使用外部远端 HTTP/SOCKS 代理；如果需要显式代理，只指向本机已纳入此设计的 Surge。
- Claude Code 使用官方目标；按用户要求，本轮不处理当前 Base URL。
- 通过当前正常 DNS 发起新连接。部署后要处理旧 DNS 缓存和已经建立的连接，不能指望它们无缝迁移。

原因不是规则数量不足：本机若只看到某个外部加密代理的 IP，便无法从网络层准确知道它内部正在访问哪个域名。多个域名共享 IP 时，IP-only 请求也不能被严格按域名区分。这是所有域名分流方案的边界，不能靠更宽 CIDR 或进程 DIRECT 消除。

当前 FFSB 为 IPv4 模式。部署须检查 D 的 A/AAAA/SVCB 结果，不能留下走其他接口的 IPv6 或地址提示旁路；不根据一次 A 查询结果声称全部记录类型均已覆盖。

## 已完成的部署前检查

1. FFSB DNS `100.70.255.254` 的实际路由为 utun100。
2. 对 `api.anthropic.com`，UDP 与 TCP DNS 都返回有效 A 回答；本次 AAAA 回答为空。该结果仅限此域名和本次状态。
3. 从 D 生成包含 25 条业务规则、25 条 Host 映射、always-real-ip 与 FFSB-Only 策略的独立语法样本，已通过本机 Surge 6.10.0 官方 `--check`，结果 OK。
4. 语法样本仅在 `/private/tmp/ffsb-design/syntax-only.conf`，为离线验证而使用的最小配置，**不得作为活动配置导入**；它不包含完整的其他代理规则。

这四项不等于部署后的运行验证通过。尤其尚未验证 Surge 内部 DNS 到 FFSB DNS 的实际路径、Surge 出站接口绑定和真实应用长连接。

## 部署步骤与验收门槛

先保存当前活动配置、模块、规则、DNS、路由与选择。构建只针对本机的候选完整配置，审查 D 的精确/通配语义与顺序，离线校验后再原子应用。失败时恢复本机前态，不以不断添加临时宽泛规则来掩盖失败。

部署后按以下顺序执行；任何关键门槛失败，均不报告“已完成”。

| 检查 | 方法 | 通过标准 |
| --- | --- | --- |
| 就绪基线 | FFSB 状态、接口、控制连接、DNS、实际业务请求 | 两客户端在线，utun100 存在，FFSB DNS 可达，真实 HTTPS 可用 |
| 精确/通配范围 | 核对 D 与实际生成规则、有效 Host、旧模块覆盖 | 25 项无遗漏、不扩大精确域名，规则在通用分流之前 |
| 系统 DNS | getaddrinfo/dscacheutil 对有效样本查询 | 真实地址、对应 utun100 路由 |
| Surge DNS | 向当前 Surge DNS 地址查询；Node resolve4、Bun c-ares | 与 FFSB DNS 语义一致，不返回 Surge fake-IP；DNS日志/定向抓包证明上游是 FFSB |
| DNS UDP/TCP/AAAA | 两种 DNS 传输与 A/AAAA；必要时 SVCB/HTTPS | 无别的解析出口或 IPv6 旁路；无记录域名不误判为隧道故障 |
| 系统入口 | 无显式代理的 HTTPS 与出口查询 | D 业务经 utun100；观察 FFSB 隧道对应流量 |
| 显式代理入口 | 单次 curl 经 Surge HTTP 端口 | D 命中 FFSB-Only，实际 socket/流量在 utun100；不出现 AI/Proxy 节点出口 |
| 多应用 | 恢复官方目标后的 Claude Code、Desktop、浏览器 | 登录、模型请求、流式传输正常；不是只检查根路径 HTTP 404 |
| 外层隧道 | 新的真实 STUN/控制/隧道请求记录，必要时物理接口定向抓包 | FFSB 服务命中 DIRECT，有实际响应，不套远端节点 |
| 集合外回归 | GitHub、ChatGPT 和本机需保留的 Tailscale 服务 | 仍按原规则与路由，未被宽泛 FFSB 规则覆盖 |
| 两种启动顺序 | 分别启动至两端就绪后再测试 | 两种顺序的有效 DNS、接口、出口结果一致；不要求未就绪时可用 |
| 重连/托管更新 | 每次重新就绪后重复路径检查 | 本机覆盖保留，DNS和目标路由正确，无手工重加IP需求 |
| 持续使用 | 建议至少30分钟实际混合使用、连续新连接及长流 | 所有已观察D连接只有FFSB出口；无持续超时、DNS错误或非预期重连 |

16 个当前可解析精确域名需逐个测试。两个无 A 地址的 MCP 根域只能核对 DNS 状态；通配域必须补真实有效子域样本，不能把 NXDOMAIN、根路径 403/404 或语法 OK 当作业务全部验收。浏览器、认证界面和长期流测试中涉及用户操作的部分由用户配合，不调用真实模型来偷偷产生费用。

流量验收应结合接口、目标路由、Surge 实际请求记录和 FFSB 流量/出口证据；只看 IP 属地、rule match 模拟或 HTTP 200 都不足以独立证明完整链路。

## 完成定义

先完成理论支持的定向部署，再按以上门槛实测。最终报告应列出通过项、失败项和未覆盖项；在核心路径或真实应用验证未通过之前，状态只能是“候选方案/待验收”，不能承诺“万无一失”。