我的博客服务部署在新加坡的 Oracle 服务器，从本地连过去，时不时会绕美国，体验较差。最近看到一个大佬的思路，很好地解决了这个问题。通过 Oracle 内网中转，优化线路。
一、思路：入口挪到韩国春川，内网穿过去
核心思路是：Oracle 每个区域之间有一条自己的内网骨干，质量远好于公网绕行。既然直连新加坡会绕美，那就把“入口”放到韩国春川——客户端先连春川，再从春川走甲骨文内网穿到新加坡落地。落地机还是原来那台，出口 IP 不变，虽然还是绕，但是绕韩比绕美强多了。
拆开是三段：
- 客户端 → 春川：走公网，春川到国内是直连线路。
- 春川 → 新加坡：走甲骨文跨区内网（DRG + 远程对等连接）。
- 新加坡落地机照常服务。
需要用到的服务 NLB、动态路由网关（DRG）、远程对等连接（RPC），全部免费，也不需要在春川开任何一台机器。唯一的代价是流量按两份计出站额度——新加坡回春川算一次，春川回客户端算一次——但每月 10TB 的免费额度，完全够用。
二、动手：拢共七步
前提：账号已升级按量付费（PAYG），否则订阅不了其他区域。区域订阅免费，但最多 3 个（含家区），订了不能退。
第一步，落地机准备。B 区（新加坡）的机器是现成的，抄下三样：私有 IP（比如 10.0.0.x）、所在 VCN 的 CIDR 网段、子网用的路由表和安全列表。
第二步，A 区（春川）建 VCN。网段千万不能和 B 区撞，B 是 10.0.0.0/16 的话 A 就用 10.1.0.0/16，否则 A 会把 B 的内网地址当成自己的。再建一个子网和互联网网关。
第三步，两边各建一个 DRG，分别附加到自己的 VCN 上；再在两个 DRG 上各建一个远程对等连接（RPC），从 B 侧发起连接，填 A 侧 RPC 的 OCID，等状态变成“已对等”。
第四步，路由表。两边都要告诉系统“去对面的流量走 DRG”：A 的路由表加一条，目的地填 B 的网段（10.0.0.0/16），下一跳选 A 的 DRG；B 的路由表反过来，目的地填 A 的网段，下一跳选 B 的 DRG。
第五步，安全列表。A 区放行 0.0.0.0/0（公网流量要从这进），B 区放行源为 A 区网段（10.1.0.0/16）的入站。
第六步，建 NLB。可见类型选公共，IP 用临时的就行。监听器选 TCP，端口填你服务实际用的端口。后端类型一定要选“IP 地址”而不是“计算实例”——计算实例只能选 A 区自己的机器，我们要填的是 B 区机器的私有 IP。注意“保留源 IP”要关掉，不关没法按 IP 加后端。健康检查协议选 TCP，端口填 B 机上真实在听的端口，并且把“失败时打开”勾上——这个健康检查偶尔抽风，勾上可以兜底。
第七步，验证。NLB 详情页看后端健康状态，正常就能拿分配的公网 IP 去连了，客户端把服务器地址一换，端口密码都不动。
三、效果
我拿落地机自己回连入口做了环回测试，现在达到了 100 到 150ms 之间——对比直连的 250ms，压缩掉的主要是公网绕行的不确定性，晚高峰不用再赌路由。
账单方面，这套东西上线之后是 0。没有新机器，没有按小时计费的服务，唯一的“消耗”是流量额度的双份扣除。
四、一个坑：v6 是空的
有人说给 NLB 加 IPv6 监听，V6 的稳定性较高。我照着配了一遍：控制台和 API 层面全都配置成功，NLB 也分配到了公网 v6 地址，看起来一切就绪——然后数据面完全不通，SYN 发出去石沉大海，健康检查也到不了后端。翻看官方 FAQ 看到一句话：NLB 目前只支持 IPv4 流量。
也就是说 v6 那套配置是能建不能用，属于服务还没上线的状态。
五、总结
这是目前对 Oracle 服务器个别区域网络质量差这个问题来说，我试过的方法里最省心的一个。
