背景

Oracle的机器配置不错，就是线路特别垃圾。我手上Oracle韩国的机器做代理节点使用体验感很差，最好的时候延迟都是200-300ms，晚高峰基本上测速就显示超时。究其原因，是用了普通线路，并没有特殊的优化，晚高峰丢包特别严重，无法正常使用。为了解决这个问题，在不换vps的前提之下，通过引入中转机场，借用机场的高速线路降低延迟，增加上网体验。

由于我这个中转机场直连香港延迟40-50ms左右，比其他地区都低，因此通过香港的节点进行中转，香港到韩国，就走国际线路。最终结果：测试的链式代理是100-130ms左右。感觉达成了 1+1 > 一 的效果。

一个具体的流程就是这样：

手机
  ↓ tun 接管所有流量
sing-box 分流
  ↓ 代理流量
机场香港节点（中转，优化线路）
  ↓ 隧道内
韩国VPS（落地，干净独立IP）
  ↓
目标网站

手机上使用的代理和节点管理的模块分别是box（sing-box内核）+Sub-Store。box是代理工具，主角；而Sub-Store在其中起到的作用主要就是修改节点信息，更新节点订阅，使我在今后换自建节点或机场的时候不需要去动sing-box的配置文件。

具体做法

Sub-Store 配置

订阅结构

订阅A：机场远程订阅链接
  └── 加「脚本操作」→ 操作节点

订阅B：自建节点（本地导入）

Collection：合并 A + B
  └── 生成一条链接填入 sing-box provider

订阅A处理

通过脚本处理订阅A的相应节点，留下延迟最低的两个香港节点。直接在订阅A中添加脚本，保存即可生效。

具体脚本如下：

const HK_COUNT = 2;
const HK_PATTERN      = /港|hk|hongkong|hong.kong/i;
const EXCLUDE_PATTERN = /2x|3x|4x|5x|x2|x3|x4|x5|倍率/i;

async function operator(proxies = [], targetPlatform, context) {
  const hkCandidates = proxies.filter(n =>
    HK_PATTERN.test(n.name) && !EXCLUDE_PATTERN.test(n.name)
  );

  const result = hkCandidates.slice(0, HK_COUNT);

  result.forEach((n, i) => {
    n.name = `固定中转-HK-0${i + 1}`;
  });

  return result;
}

以后换机场：只改订阅A的链接，sing-box 配置永远不用动。

sing-box的链式代理结构

订阅链接

原版的sing-box内核是不支持订阅链接的格式的，我用的是reF1nd分支版本，支持导入订阅链接，特别方便（原版不支持这个实在是遗憾）。

{
  "type": "remote",
  "tag": "订阅名",
  "url": "http://127.0.0.1:3000/download/collection/sub",
  "exclude": "剩余流量|到期|重置|官网",
  "user_agent": "sing-box",
  "path": "./proxy_provider/provider1.json",
  "download_detour": "🎯 本地直连"
}

不管订阅A和B怎么改，只要组合订阅的地址不变， 这个配置中的订阅链接就不需要动，一直是： “http://127.0.0.1:3000/download/collection/sub” ，方便吧？

链式代理

设置中转节点组
{
  "type": "urltest",
  "tag": "🛫 中转-自动选优",
  "use_all_providers": true,
  "include": "固定中转-",
 ......
}
具体实现
{
  "type": "vless",
 ......
  "flow": "xtls-rprx-vision",
  "tls": {
    "enabled": true,
    "reality": { ... }
  },
  "detour": "🛫 中转-自动选优"
}

detour 是链式代理的核心字段，让连接先经过中转节点再到VPS。

其余配置略。

结论

经过一段时间的使用下来，这个效果明显好过直连VPS，晚高峰也可以流畅看视频。

什么？你问为什么不直接用机场？？

OK，You got me。