我来确认自己的使用方式是否存在什么问题

我在 Debian12
装了 ffsb

curl -fsSL https://link.fufeishangban.com/downloads/ffsb-install.sh | sudo bash

看起来连接成功了

$ ffsb status
OS: linux/amd64
Daemon version: 0.1.25
CLI version: 0.1.25
Profile: default
Management: Connected
Signal: Connected
Relays: 2/2 Available
Nameservers: 0/0 Available
FQDN: t3680.ffsb.internal
FFSB IP: 100.70.127.221/16
Interface type: Kernel
Wireguard port: 51820
Quantum resistance: false
Lazy connection: true
SSH Server: Disabled
Networks: -
Peers count: 3/4 Connected

$ ffsb up
Already connected # 我通过这里判断认为链接成功了

网页正常登录可以正常访问, 配合 WebRTC Network Limiter

使用 ClashVerge 做网络代理

  • 虚拟网卡模式(TNU 模式) 没有打开
  • 全局扩展覆写配置增加了 付费上班 指导内容
    # https://ffsb.sg/me/proxy?tab=proxy
    # 不过按照这个网页的说法 , 我当前的情况好像可以不加这些配置 ;
    prepend-rules:
     - PROCESS-NAME,ffsb,DIRECT
     - PROCESS-NAME,ffsb-service,DIRECT
     - PROCESS-NAME,ffsb.exe,DIRECT
     - PROCESS-NAME,ffsb-service.exe,DIRECT
     - DOMAIN-SUFFIX,anthropic.com,DIRECT
     - DOMAIN-SUFFIX,claude.ai,DIRECT
     - DOMAIN-SUFFIX,claude.com,DIRECT
     - DOMAIN-SUFFIX,clau.de,DIRECT
     - DOMAIN-SUFFIX,claudemcpclient.com,DIRECT
     - DOMAIN-SUFFIX,claudemcpcontent.com,DIRECT
     - DOMAIN-SUFFIX,claudeusercontent.com,DIRECT
     - DOMAIN-SUFFIX,join.fufeishangban.com,DIRECT
     - DOMAIN-SUFFIX,ffsb.sg,DIRECT
     - DOMAIN-SUFFIX,hcaptcha.com,DIRECT
     - DOMAIN,api.ipify.org,DIRECT
     - DOMAIN,icanhazip.com,DIRECT
     - DOMAIN,ifconfig.me,DIRECT
     - DOMAIN,ip.net.coffee,DIRECT
    
  • zsh bash 都配置了 于 Clash 相关的代理
    export http_proxy="http://127.0.0.1:port"
    export https_proxy="http://127.0.0.1:port"
    export NO_PROXY="localhost,127.0.0.1"
    #...
    

诊断信息

$ curl -fsSL ``https://ffsb.sg/downloads/ffsb-doctor.sh`` | bash
FFSB 自检报告   2026-10-31 17:27:29   Linux x86_64
------------------------------------------------------------
  ✅ DNS 解析: link.fufeishangban.com -> 147.93.172.146
  ⚠️  检测到代理环境变量 (ffsb 守护进程不走代理):
       https_proxy=http://127.0.0.1:1234
       http_proxy=http://127.0.0.1:1234
  ✅ 直连控制端点可达: link.fufeishangban.com:443 (TCP 0.11s, TLS 握手 0.30s, HTTP 200)
     经代理可达 (HTTP 200) —— 说明这台机器只能通过代理出网
  ✅ 未发现其它 VPN/隧道网卡
     路由: 147.93.172.146 dev wt0 table netbird src 100.70.127.221 uid 1000 
  ⚠️  到服务器走了 ffsb 自己的隧道 wt0 (路由环路) —— 请先 ffsb down 再重试
  ✅ 路由策略正常 (无把全部流量导入自定义表的规则)
       Management: Connected
       Signal: Connected
  ✅ ffsb 控制连接正常 (Management + Signal 均 Connected)
     隧道传输: P2P, 本端候选地址 192.168.8.202
------------------------------------------------------------
各域名实测(预期 vs 实际):
  api.ipify.org            [A/专线]
       预期: FFSB 出口 IP  →  实际: 138.75.58.11
  icanhazip.com            [A/专线]
       预期: FFSB 出口 IP  →  实际: 138.75.58.11
  ifconfig.me              [A/专线]
       预期: FFSB 出口 IP  →  实际: 138.75.58.11
  ipinfo.io/ip             [B/对照,不在FFSB名单里]
       预期: 你自己的真实公网 IP  →  实际: 106.47.31.201
  checkip.amazonaws.com    [B/对照,不在FFSB名单里]
       预期: 你自己的真实公网 IP  →  实际: 106.47.31.201
  api.anthropic.com        [C/专线]
       预期: 2xx-4xx 均算通  →  实际: HTTP 404 · 0.475890s (通)
  claude.ai                [C/专线]
       预期: 2xx-4xx 均算通  →  实际: HTTP 403 · 0.505130s (通)
  claude.com               [C/专线]
       预期: 2xx-4xx 均算通  →  实际: HTTP 200 · 1.155652s (通)
  anthropic.com            [C/专线]
       预期: 2xx-4xx 均算通  →  实际: HTTP 301 · 0.501705s (通)
  claudeusercontent.com    [C/专线]
       预期: 2xx-4xx 均算通  →  实际: HTTP 301 · 0.518008s (通)
------------------------------------------------------------
  ✅ A组(专线出口)和 B组(你本机真实出口)IP 不同 —— 专线分流确实生效了, 只有 FFSB 域名走了专线
------------------------------------------------------------
小结:  ✅ 6 正常   ⚠️ 2 提醒   ❌ 0 异常
诊断建议:
  · ffsb 已正常连接 (Management/Signal 均 Connected), 网络这块没问题, 无需处理。若 Claude 专线仍显示异常, 点客户端「检测 Claude 线路」看出口 IP。
  · 本报告全绿, 但浏览器打开 claude.ai 还是不行(比如跳转 app-unavailable-in-region /
    连接被终止)? 大概率是浏览器自己绕过了系统 DNS, 本脚本用的是 curl/系统解析器,
    测不出这种情况, 两个常见原因逐个排除:
    1) Chrome/Edge 开着「安全 DNS」(DNS-over-HTTPS): 域名解析走到 Google/Cloudflare
       等公共 DoH 服务器, 绕开了 ffsb 的域名路由拦截, 请求直接从本机真实网络出去。
       关掉: 设置 → 隐私设置和安全性 → 安全性 → 使用安全 DNS → 关闭(或选"使用你当前
       的服务提供商")。
    2) 系统 IPv6 泄漏: 双栈网络下, 没被专线覆盖到的目标可能从本机真实 IPv6 出口
       直连出去。可以先在系统网络设置里临时关掉 IPv6, 或联系客服帮忙确认。
客服: [email protected]   社区: https://fufeishangban.com

claude_test_without_clash() {
  env \
    -u HTTP_PROXY -u http_proxy \
    -u HTTPS_PROXY -u https_proxy \
    -u ALL_PROXY -u all_proxy \
    claude "$@"
}

claude_test_with_clash() {
  env \
    HTTP_PROXY="http://127.0.0.1:1234"  http_proxy="http://127.0.0.1:1234" \
    HTTPS_PROXY="http://127.0.0.1:1234" https_proxy="http://127.0.0.1:1234" \
    NO_PROXY=="localhost,127.0.0.1"     no_proxy="localhost,127.0.0.1" \
    claude "$@"
}

上述两种启动方式
ffsb 保持连接的情况下(我想知道我的理解对不对)

  • 1. 开启 ClashVerge(不开系统代理) 时候 claude_test_with_clash → 可以正常使用 Claude, 是吗? ; 我试过了 没发现问题 .
  • 2. 开启 ClashVerge 时候(系统代理) claude_test_with_clash → 可以正常使用 Claude, 是吗?

总的来说 ClashVerge 关闭 TUN 情况下

  • 3. shell 环境 带与不带 http_proxy HTTP_PROXY 对使用 ffsb + claude 有什么负面影响吗 ?
  • 4. 是否开启 ClashVerge 系统代理 对使用 ffsb + claude 有什么负面影响吗 ?

希望问清楚 , 不要给后续使用增加不必要的麻烦
如果大家有什么其他要告知的也可以告知下


我想我将来大概率会在这几种情况下切换

  1. 可以使用 ffsb + claude
  2. 可以使用 ffsb + clash verge(非系统代理) + claude claude_test_without_clash
  3. 尝试避免 ffsb + clash verge( 系统代理 ) + claude claude_test_without_clash
  4. 应该拒绝 ffsb + clash(系统代理开) + chrome claude ; 此时浏览器 ip 检测到 非预期的 机场 IP

非常有水平的帖子, 很像详细, 容我先顶后看

你这个情况, 要测一下, 正常的 http 是不是走 ffsb,
curl ifconfig.me 看看IP出口对不对, 不对就是被系统环境变量劫走了

以前

在上述前提下(开与不开 Clash 系统代理结果相同) , curl 测试结果如下

$   env \
    -u HTTP_PROXY -u http_proxy \
    -u HTTPS_PROXY -u https_proxy \
    -u ALL_PROXY -u all_proxy \
    curl ifconfig.me
138.75.xxx.xxx%   # 符合预期的 新加坡 IP

$ curl ifconfig.me
176.122.xxx.xxx%  # 不符合预期的 我的机场 IP

在上述前提下(同时 Clash 没有开系统代理) , claude 测试结果如下

  1. 直接使用 claude cli ; /status 查看到包含代理信息 Proxy: http://127.0.0.1:1234
  2. claude_test_without_clash 启动 claude cli ; /status 查看不包含代理信息`

Clash 开系统代理的情况下

  • claude_test_without_clash 启动 claude cli ; /status 查看不包含代理信息`

关于 Chrome + WebRTC Network Limiter

  • ffsb连接正常 + Clash 不开系统代理的时候, ip.net.coffee 检测到是 符合预期的 新加坡IP
  • ffsb连接正常 + Clash 打开系统代理的时候, ip.net.coffee 检测到是 机场 IP

总的来说

  • 如果要使用 Chrome 访问 Claude 好像不该使用 Clash 系统代理 .
  • ffsb + clash(关闭系统代理) + claude_test_without_clash 看起来安全
  • ffsb + clash(开启系统代理) + claude_test_without_clash 看不出异常 , 但是考虑到 Chrome 的表现 + 原理细节不够清晰 , 我个人会尝试避免