甲骨文丢包？用「春川 NLB 进、节点出」白嫖一条稳定线路

背景

手上有几台甲骨文新加坡的机器，拿来做节点的时候发现三网差异很大：

移动没什么可说的，电信联通就很难受。

换 IP 没用。 我在同一台机器上加了几个预留公网 IP，平行测了一轮，结果都差不多，最后全部释放了。线路好坏取决于甲骨文新加坡到国内的上游，跟具体哪个 IP 无关，所以靠刷 IP 解决不了。

思路

跨境最容易出问题的是出国那几跳。那就让国内用户先连到离国内更近、互联更好的地方，剩下的路走甲骨文自己的骨干网：

客户端 ──(公网，跨境段短)──▶ 春川 NLB:443 ──(DRG/RPC，Oracle 内网)──▶ 新加坡机器 内网IP:443 ──▶ 目标网站

• 跨境段变短：国内到韩国的距离和互联都比到新加坡好。
• 后半段走内网：春川到新加坡走跨区域对等连接，不经过公网，也不过墙。
• 出口不变：网站看到的还是新加坡 IP，解锁情况和原来一样。
• NLB 只做四层透传：不拆 TLS，Reality、VLESS 等协议照常用，后端什么都不用改。

费用（重点：可以 0 元）

前提和建议：

• 账户要升级到 PAYG：免费账户只能用主区域，订阅春川需要升级。升级后 Always Free 资源照样免费。
• 一定要开预算告警：比如设一个 £1 或 $1 的月度预算，实际花费超过 1% 就发邮件，防止意外扣费。我跑了一个月，账单还是 0。

搭建步骤

下面用 OCI CLI 演示，控制台点也一样。假设：

• 新加坡 VCN：10.0.0.0/16，后端机器内网 IP 10.0.0.69，Xray 监听 443。
• 春川 VCN：10.77.0.0/16，子网 10.77.1.0/24。
• 两边 CIDR 绝对不能重叠，否则路由会出问题。

1. 订阅春川区域

控制台进入 Governance → Region Management，订阅 ap-chuncheon-1。

坑：刚订阅完的一两分钟里，CLI 调用春川会报 401 NotAuthenticated。这是 IAM 还在同步，等两分钟再操作就好，不是你配置错了。

2. 春川侧网络

在春川创建：

• VCN 10.77.0.0/16，加一个 Internet Gateway。
• 子网 10.77.1.0/24（公网子网）。
• 路由表：
  • 0.0.0.0/0 → Internet Gateway
  • 10.0.0.0/16 → 春川 DRG（第 3 步创建）
• 安全列表：
  • 入站：TCP 443，来源 0.0.0.0/0
  • 出站：TCP 443，目标 10.0.0.0/16（健康检查和转发都要用到）

3. 两边各建一个 DRG，并挂到各自的 VCN

oci network drg create --compartment-id $C --display-name drg-kr --region ap-chuncheon-1
oci network drg-attachment create --drg-id $KR_DRG --vcn-id $KR_VCN --region ap-chuncheon-1
# 新加坡同理：drg-sg 挂到新加坡 VCN

4. 远程对等连接（RPC）

# 两边各建一个 RPC
oci network remote-peering-connection create --compartment-id $C --drg-id $SG_DRG --region ap-singapore-1
oci network remote-peering-connection create --compartment-id $C --drg-id $KR_DRG --region ap-chuncheon-1

# 从一侧发起连接
oci network remote-peering-connection connect \
  --remote-peering-connection-id $SG_RPC \
  --peer-id $KR_RPC --peer-region-name ap-chuncheon-1 --region ap-singapore-1

等两边状态都变成 PEERED。

5. 新加坡侧路由和防火墙

• 路由表：加一条 10.77.0.0/16 → 新加坡 DRG。
• 安全列表：放行 TCP 443，来源 10.77.0.0/16。
• 机器上的 ufw / iptables：也要放行 10.77.0.0/16 访问 443。

坑：用 CLI 改安全列表和路由表是整表覆盖，不是追加。一定要先 get 现有规则，合并之后再 update --force，否则原有规则会被清空，SSH 都可能断。改之前记得备份 JSON。

建议：后端 443 只放行 10.77.0.0/16，公网直接关掉。这样后端 IP 不暴露，被墙的风险也小。

6. 创建 NLB

oci nlb network-load-balancer create --compartment-id $C --region ap-chuncheon-1 \
  --display-name chuncheon-relay --subnet-id $KR_SUBNET \
  --is-private false --is-preserve-source-destination false

oci nlb backend-set create --region ap-chuncheon-1 --network-load-balancer-id $NLB \
  --name bs-sg --policy FIVE_TUPLE --is-preserve-source false \
  --health-checker '{"protocol":"TCP","port":443}' \
  --backends '[{"ipAddress":"10.0.0.69","port":443}]'

oci nlb listener create --region ap-chuncheon-1 --network-load-balancer-id $NLB \
  --name relay-443 --default-backend-set-name bs-sg --port 443 --protocol TCP

关键参数：

• is-preserve-source false（必须关）：开着的话，后端会看到客户端真实 IP，然后尝试直接从新加坡公网回包，回程不对称，连接直接失败。关掉以后，后端看到的来源是 NLB 的内网 IP（10.77.x.x），回包老老实实走 DRG 回去。

• 健康检查用 TCP 443：Reality 不会响应 HTTP 探测。

• 空闲超时：NLB 默认 TCP 空闲超时 360 秒，长时间不传数据的连接会被断开，一般无感。

  健康检查变成 OK 后，客户端把地址换成 NLB 的公网 IP，其他参数（UUID、Reality 公钥、SNI 等）和直连完全一样。

实测

测试方法：从国内两台多线云机器（阿里云、腾讯云）各做 20 次 TCP 握手，晚上测的。

另外跑了端到端测试，打开 Google 首页 0.6–1.25 秒。

说明一下：多线机房的线路比家宽好，电信、联通、移动家宽的真实体验还要以用户反馈为准。我目前只能说「明显比直连稳」，不敢吹三网都完美。

顺带的几个发现

1. 新加坡的 IPv6 对联通很友好。 甲骨文新加坡 IPv6 走 Singtel（AS7473）直连联通 AS4837，联通延迟约 112ms，IPv4 要 250ms 左右。不过电信、移动走 IPv6 反而更差。所以我把同一台机器的 IPv4 和 IPv6 分别做成「移动优选」和「联通优选」两个节点。
2. 开了 IPv6 记得改 Xray 的出站策略。 机器有了 IPv6 之后，Xray 默认可能优先走 IPv6 出站，网站看到的出口就变了。把 direct 出站设为 "domainStrategy": "UseIPv4v6"，就能优先走 IPv4。
3. 别只看 ICMP。 运营商的 DNS 之类测试点会限速 ICMP，有台机器 ping 移动显示 361ms，实际 TCP 握手只有 69ms。测节点质量还是 TCP ping 更准。
4. 新区域、安全列表、路由表的那几个坑，上面步骤里都写了，照着来基本一次成。

适合谁

• 手上有甲骨文新加坡或其他区域的机器，但电信联通体验很差。

• 想要一个 0 成本的兜底节点。

• 账户已经是 PAYG，或者愿意升级（记得开预算告警）。

  同样的玩法可以套到其他组合，比如用春川当入口、出口放在日本或美国的甲骨文机器，只要两边 VCN 能对等连接就行。