oracle3 cc-switch 国内中转站经家庭出口分流方案

[!info] related notes

• [[oracle-osaka-amd-development-vps|Oracle 大阪 AMD 高性能开发 VPS（oracle3）]] — 方案载体与现状
• Resin 代理池网关 — 演进的出口调度层
• ImmortalWRT 配置 — 家庭出口载体
• VPS 网络代理 MOC、机场与代理订阅 MOC
• OCI VPS Tailscale 远程访问、搭建中转+落地节点

一句话

oracle3 上 cc-switch 的出站流量按目标域名分流：到国内中转站的流量经 Tailscale 走家庭宽带（ImmortalWRT）出口，其余流量保持现状直连——让流量走它该走的出口，而不是把全部流量都堆到一条路上。

问题背景

oracle3（OCI 大阪）直连国内 AI 中转站经常连不上、首次响应慢。根因是「OCI 大阪 ↔ 国内中转站」的国际线路质量差（绕路、丢包、跨运营商），部分中转站还会对数据中心 IP 做风控。这些中转站本身就是 OpenAI 服务的提供方（不存在「直连 OpenAI」的替代路径），目标不是换供应商，而是改善到达中转站的线路：让 oracle3 的上游流量借用家庭宽带这条国内线路。

研究结论（2026-08-06）

1. resin：确认是开源项目 Resinat/Resin（代理池网关，2k stars，MIT）。能力：聚合订阅节点、健康检查/熔断、Platform 节点池过滤、Sticky Session 固定出口 IP、HTTP/SOCKS5/反向代理三种接入、RESIN_PROXY_BYPASS 直连白名单。定位是出口调度层，不做域名级分流——「该走哪个出口」的决策仍需外层工具（sing-box）承担。
2. cc-switch（Aaroen/cc-switch-cli，ccs 3.16.5）：无上游/出站代理配置能力，代理直接拨号 provider 的 base_url。因此分流层必须外置：方案 A = HTTPS_PROXY 环境变量注入本地 sing-box；方案 B = sing-box TUN 透明代理（fallback）。
3. ai-proxy 仓库（D:\home\projects\ai-proxy）：CPA + 注册机 + AxonHub 网关栈；platform/egress/ 已有 WARP relay / tcp_relay_11080.py 等出口概念可借鉴。该仓库不含 resin，resin 需要独立部署；后续注册机流水线可与本方案出口层衔接。

架构

codex / coding-coach / 其他客户端
   ↓  CODEX_PROXY=http://127.0.x.x:15721
cc-switch（ccs，127.0.x.x:15721）            ← 多中转站 + 请求级故障转移（现状保留不动）
   ↓  HTTPS_PROXY=http://127.0.x.x:2080（方案 A，实施时实测）
sing-box 分流决策层（127.0.x.x:2080）
   ├─ 12 个国内中转站域名 → home-exit outbound ──→ Tailscale ──→ ImmortalWRT mixed-inbound（:2081，tailscale0 only）
   │                                                            └── 家庭宽带直连（DIRECT，不走科学上网链路）
   └─ 其余流量 → direct outbound ──→ 现状直连（OCI 原生网络）

[演进] home-exit ──→ Resin（127.0.x.x:2260，Platform=HomeCN）──→ 出口节点池（家庭出口 + 未来机场/住宅代理）

各层要点

oracle3 分流决策层（sing-box）

• 安装 sing-box 二进制，systemd 常驻
• 本地 mixed-inbound（HTTP + SOCKS5）127.0.x.x:2080
• outbound：
  • direct（默认出口，保持现状）
  • home-exit：HTTP 代理指向家庭出口 http://<user>:<pass>@<immortalwrt-tailscale-ip>:2081
• route：12 站 domain_suffix → home-exit；final: direct
• cc-switch 注入：为 ccs 建 systemd service（或启动脚本）带 HTTPS_PROXY=http://127.0.x.x:2080，替换现在的手动后台启动

匹配清单（domain_suffix 归一）：fluxionai.space、ooioo.work、congee.pro、true-sota.com、aierxin.cc、anyrouter.top、aitoken.forum、cpa.bakersean.top、ark2.cn、7r.fit、jiji.cc、0xpsyche.me

家庭出口（ImmortalWRT VM，N100 PVE 上）

• 装 sing-box（opkg 或二进制）或复用 nikki/mihomo，新增独立 mixed-inbound
• 仅 bind tailscale0（ImmortalWRT 的 tailscale 接口）端口 2081，带用户名密码认证——tailnet-only + 认证双保险，绝不暴露公网
• 出口策略：DIRECT 直连家庭宽带——绝不能走 nikki 的 mihomo 代理规则（否则流量进科学上网链路二次绕路，失去意义）

演进出口调度层（Resin，可插拔）

当前只有 1 个家庭出口时不引入 Resin（sing-box 直连 ImmortalWRT，故障面最小、迁移成本最低）。在多出口 / AI 注册机阶段启用：

• oracle3 上 Docker 部署 ghcr.io/resinat/resin（RESIN_LISTEN_ADDRESS=127.0.x.x + 强 RESIN_ADMIN_TOKEN / RESIN_PROXY_TOKEN）
• 把 ImmortalWRT mixed-inbound 作为 HTTP 节点导入，建 Platform HomeCN
• sing-box home-exit 改指向 Resin（-U "HomeCN:<token>"），由 Resin 负责节点健康与调度
• RESIN_PROXY_BYPASS="localhost;127.*;10.*;192.168.*;<local>" 防止内部流量误入代理池
• 注册机场景：用 Sticky Session（HomeCN.<account>:<token> 或反向代理 + X-Resin-Account 头）把同一账号绑定稳定出口 IP——家庭住宅 IP 更接近真实用户，与 ai-proxy 仓库的注册机流水线衔接

验证方法（实施阶段）

1. 基线：oracle3 直连每站 curl -o /dev/null -s -w "%{http_code} %{time_total}" 记录成功率/延迟
2. 出口对比：经 home-exit（家庭出口）curl 同一批站，逐站对比
3. 决策：家庭出口更优（原本失败转成功，或延迟显著下降）→ 保留在规则；个别境外 CDN 站若更差 → 移出规则走直连
4. 端到端：codex exec 走 ccs → sing-box → home-exit 发真实请求，查 sing-box 日志确认 outbound 命中
5. 熔断联动：ccs 的请求级故障转移继续兜底，某站挂了自动切下一个

备选方案对比

维度	方案 A：HTTPS_PROXY 注入	方案 B：TUN 透明代理
侵入性	低（只改 ccs 进程环境变量）	中（root + tun 设备 + 路由）
依赖	cc-switch 尊重环境变量（Go 标准库默认支持，需实测）	无，任意程序透明
回退	改环境变量即回退	需清理 tun/路由，回退面大
决策	首选	fallback

Resin 接入时机：当前 1 个出口时不值得引入调度层；演进阶段（多出口 / 注册机）再启用，避免为单一出口叠加复杂度。

迁移与扩展

• 新 VPS 快速重建：把 sing-box 配置模板 + 12 站域名清单 + ccs systemd unit + Resin docker-compose 模板入仓库（ai-proxy 或独立 infra 仓库），一条 install 脚本 + env 即重建，满足「任何新 VPS 快速复现」
• 多出口：Resin 导入多个订阅，Platform 按地区/用途分池，家庭出口只是其中一池
• 注册机：Resin Sticky Session + 家庭住宅出口，与 ai-proxy 注册机流水线衔接，账号级固定出口 IP

实施记录（2026-08-06 已落地）

状态：链路层方案已实施并验证通过；模型响应层被上游中转站故障阻断，待上游恢复后复验 codex exec 端到端。

家庭出口（ImmortalWRT imm103，N100 PVE）

• 部署独立 mihomo 实例（/etc/mihomo-exit/config.yaml + init.d mihomo-exit，procd 常驻）——实际决策：复用已有 /usr/bin/mihomo，未装 sing-box（比方案预期的 opkg 安装更轻）
• mixed-inbound：100.121.x.x:2081（仅 bind tailscale0），用户名密码认证（凭据存于 imm103 /etc/mihomo-exit/config.yaml，不入库），出口规则 MATCH,DIRECT（家庭宽带直连，不进 nikki 科学上网链路）
• 验证：oracle3 经 http://exituser:***@100.121.x.x:2081 访问 api.ipify.org 返回家庭宽带公网 IP 40.82.x.x（非 OCI 的 161.33.x.x）

oracle3 分流决策层（sing-box）

• sing-box v1.13.16 官方 release 安装，systemd 常驻（/etc/sing-box/config.json）
• mixed-inbound 127.0.x.x:2080；outbound home-exit → 100.121.x.x:2081；route：11 站 domain_suffix → home-exit，final: direct
• 验证：日志确认 ooioo.work / fluxionai.space / congee.pro 命中 outbound/http[home-exit]，api.ipify.org 走 direct

ccs 接入（方案 A 确认 ✅）

• ccs 由手动后台启动迁移为 systemd 管理（/etc/systemd/system/ccs.service，Type=forking 适配其 daemon 化行为）
• 注入 HTTPS_PROXY=http://127.0.x.x:2080 / NO_PROXY=127.0.x.x,localhost——验证确认 ccs 尊重 Go 环境变量代理，其上游流量全部经 sing-box 分流（日志铁证：触发请求后 fluxionai/ooioo/anyrouter 均命中 home-exit）
• 决策 A vs B：确定为方案 A，无需 TUN 透明代理

逐站对比与决策（直连 vs 家庭出口）

站	直连	家庭出口（经 sing-box）	决策
congee.pro	3/3 200	3/3 200	保留 home-exit
aierxin.cc	3/3 200	3/3 200	保留 home-exit
anyrouter.top	3/3 200	3/3 000（连接失败）	移出，走 direct
fluxionai.space	models 200 / responses 502	models 200 / responses 502	保留（上游 502 与链路无关）
ooioo.work	/v1/models 401	/v1/models 401	保留（上游模型列表为空）

端到端与上游现状

• 链路级端到端通过：curl -x http://127.0.x.x:2080 https://fluxionai.space/v1/models 返回 200（~1-1.8s），真实模型列表（6 个模型，含 gpt-5.6-sol）——完整链路（客户端 → sing-box → 家庭出口 → 中转站 → 业务数据）跑通
• 模型响应层被上游阻断（与方案无关，直连同样失败）：
  • fluxionai /v1/responses 持续 502（4 次重试，直连/家庭出口一致）
  • ooioo 模型列表为空（无 gpt-5.6-sol 渠道，503 model_not_found）
  • anyRouter 家庭出口连接失败 + 上游 负载已经达到上限（500）
• 结论：方案把「链路」问题解决了；当前不可用是上游中转站状态（这正是用户最初观察到的另一面），需上游恢复后复验 codex exec

实施清单（2026-08-06 状态）

• 确认 ImmortalWRT 的 tailscale IP 与 tailscale 客户端状态（tailscale status → immortalwrt = 100.121.x.x）
• ImmortalWRT 配 mixed-inbound（tailscale0:2081 + 认证，DIRECT 出口）【决策：复用 mihomo 独立实例，未装 sing-box】
• oracle3 安装 sing-box 分流层，加载 12 站规则（逐站验证后收敛为 11 站）
• 验证方案 A：ccs 设 HTTPS_PROXY 后流量确实经过 sing-box【决策：A 成立，未启用 TUN】
• 逐站对比 直连 vs 家庭出口【决策：anyrouter.top 移出，其余 11 站保留】
• [~] codex exec 端到端验证【链路通过；模型响应被上游 502/无渠道阻断，待上游恢复后复验】
• （待办）上游恢复后复验 codex exec 经 ccs → 家庭出口完整链路
• （可选）codex config.toml 切回 http://127.0.x.x:15721（ccs 多站故障转移 + 家庭出口分流，需用户确认）
• （可选演进）部署 Resin + HomeCN Platform + 注册机 Sticky Session

风险与回退

• 家庭链路故障（ImmortalWRT 重启/断网）：sing-box 配置 reload 移除规则快速回直连；Tailscale DERP 中继兜底（打洞失败仍可达，延迟升高但可用）
• 个别中转站线路在家庭宽带也不佳（境外 CDN 站）：验证阶段剔除，规则保持白名单化
• 风控不全是线路问题：余额不足（www.jiji.cc）、服务端策略（503）等，家庭出口只解决线路与 IP 类型问题，不保证全部恢复