foru17/homelab/cross-border-network

跨境网络方案设计（补短板 · 香港枢纽 · 便宜落地）

帮用户测量、诊断并优化自己的跨境网络。思路来自一套实际在跑的个人网络（两个家、三条深港专线、香港落地、东京 / 新加坡家宽出口、美国 CN2 GIA 前门），公开版见 <https://net.zuoluo.tv>。

这是方法论 + 检查清单，不是一键脚本。没有任何账号、IP、域名、节点配置被打包进来；所有具体值都来自用户自己。

核心思路（先讲给用户听）

1. 只在最贵的那一段花钱。 跨境真正的短板只有一段：家 → 香港。国内段家宽不差，香港往外国际带宽充足，最拥堵、最不稳定的是跨境那一跳。把这一跳换成专线（云联网 CCN / IPLC / IEPL），最好两条以上互为备份。专线的出口城市按所在地挑：华南多走广州 / 深圳 → 香港，华东、华北也可以考虑上海 → 日本。
2. 香港当枢纽。 多条专线落到同一台香港机器：出口只有一个，分流规则只维护一份；哪条线坏了，按实时延迟切到另一条。
3. 落地选物美价廉。 短板补上后，后面的机器不需要贵价线路。便宜 VPS、免费额度、WARP、各地家宽都能当出口。直连就很快的机器往往很贵；靠架构反而更灵活。
4. 需求决定出口，而不是一台机器包打天下。 游戏 / 低延迟要香港；Netflix 可能要台湾 / 新加坡；Spotify 可能要日区；TikTok 香港刷不了，要日本等；AI 服务通常要美国。按服务分流到不同地区出口。
5. 机器之间用 Tailscale 组网 + 挑好的中继。 所有机器一张内网；两台之间公网不好走（跨运营商黑洞、晚高峰丢包），就选一台线路好的机器做中继 / 自建 DERP。
6. 美国可以不绕香港。 电信用户可以直走 CN2 GIA 到洛杉矶，当作国内访问美国的前门；应用放在更便宜的美西机器上。
7. 安全底线。 管理面不上公网（只认 tailnet）；家宽出口只出不进；对外入口都要鉴权或白名单；数据多地加密备份；按量计费资源设上限告警。

工作流程

按顺序走，每一步都把结论写进最终方案文档。

1. 了解现状（先问，不要猜）

一次性问清楚，缺什么就标注「待补」继续往下：

• 家的情况：几个家、各自运营商（电信 / 联通 / 移动）、大致省份（只需要到省，用于判断到哪个入口近；不要求也不记录具体城市和地址）、有没有公网 IPv4 / IPv6、网关设备（软路由 / OpenClash / 其他）。
• 使用场景：开发（GitHub / Docker / 依赖拉取）、AI 工具、流媒体（Netflix / YouTube / Spotify / TikTok）、游戏、视频会议、在外手机使用。
• 现有资源：现在用的网络方案 / 自建节点 / 专线、各自价格和到期时间。
• 预算与维护意愿：每月可接受的费用，愿不愿意维护服务器。
• 痛点：晚高峰丢包？单线程下载慢？某些服务解锁不了？在外回家不稳？

如果用户只是偶尔看视频、不想维护服务器，直接建议使用普通的网络方案，或一台 CN2 GIA 美国机器，不要硬推复杂方案。

2. 测量（用数据说话）

按 references/measurement.md 的方法测：

• 延迟用「复用连接」测，不要用每次新建连接的请求时间（后者含代理握手，会高 2–4 倍，容易误判）。
• 带宽看单连接，同时记 4 连接；至少测 3 轮取中位数，单轮差异可达一倍。
• 晚高峰（20:00–23:00）至少测一轮；丢包、最大值和中位数一起记。
• 在家和在外（手机 4G/5G）分别测。
• scripts/line-bench.sh 可以在 Linux / OpenWrt 上对一组节点批量测（需要 mihomo 内核）。

3. 诊断短板

把链路拆成段：家 → 国内入口 → 跨境段 → 香港落地 → 最终出口，逐段看延迟和丢包。常见结论：

4. 设计方案

参考 references/architecture.md（分层模型 + 参考拓扑）输出：

• 入口层：家里网关 / 手机客户端如何进入；国内入口机（广州 / 上海等离家近的云）。
• 跨境层：选哪几条线、主备关系、调度方式（按实时延迟切换）。
• 落地层：香港 hub 机器；是否需要第二落地做热备。
• 出口层：香港机房 IP、WARP、各地家宽、美国 CN2 GIA 直达；每个出口对应哪些服务（references/routing.md）。
• 组网层：Tailscale 内网、中继 / DERP 放在哪。
• 安全层：references/security.md 的基线逐条对照。
• 成本表：按「国内 / 专线 / 境外 / 美国」分组，人民币和美元分列，年付折月。

给出 2–3 档方案（省心档 / 均衡档 / 折腾档），写清每档的月成本、预期延迟和带宽、维护量。

5. 落地与验证

• 每改一处都复测（同一方法、同一时段），和改前对比。
• 把踩过的坑记下来；先看 references/pitfalls.md，很多问题已经有人踩过。
• 需要新开一台落地机时，可用同仓库的 skills/edge-node-provision 标准化部署。

输出格式

最终给用户一份方案文档，包含：

1. 现状与痛点（一段话 + 测量表）
2. 短板在哪（逐段数据）
3. 推荐方案（分层说明 + 一张拓扑图，可用 Mermaid）
4. 分流表（服务 → 出口）
5. 成本表（分组 + 人民币 / 美元）
6. 安全检查结果
7. 实施步骤与每步的验证方法

规则

• 隐私：不要让用户贴出 IP、域名、端口、UUID、密码、订阅链接；方案里一律用占位符（<HK_HUB>、<ENTRY_GZ>）。用户的家只写「家 A · 联通」这类，不写城市和地址。
• 不要推荐违法用途；只讨论网络性能、稳定性与合规的访问需求。
• 不替用户下单，价格和线路随时会变，提醒用户以商家页面为准、先买月付试用再年付。
• 数字要可复现：给出的延迟 / 带宽要写明测量方法、时段和轮数。