Oracle VPS 的代理问题：有时不是协议，而是路由和配置层

一开始的“代理失败”可能发生在不同层

旧笔记把 OCI 安全列表、端口连通性、链路黑洞、Cloudflare TLS 模式、客户端代理规则和落地节点连通性放到一起检查。它们都可能表现为请求失败，但不能用一个统一配置就解释所有现象。

曾经差点相信错误的计算结果

其中一段记录特别值得保留：最初怀疑 Reality 相关公钥有问题，后来使用成熟库校验，发现手写算法才是错误来源；原有公钥本来就是对的。它说明调试工具本身的正确性也必须验证。

另一轮 Nikki 中转问题

使用 Mihomo/Nikki 中转自建节点时，我还遇到过节点重名、流量没有按预期经过中转、不同路径可达性不一致的问题。配置里的名称看起来正确，不保证测速或真实请求就走了那个节点。

补充：走代理了，为什么 TLS 还是握手失败？

另一份历史记录描述了这样一组对照：同一站点在远端环境可以正常完成 TLS/HTTP 请求，而本地走某条代理路径时却在 TLS 阶段失败。两边得到的目标 DNS 地址不同。

这件事让我重新区分两步：代理决定流量从哪里发出，不一定替客户端决定域名最初被解析成哪个地址。有时 TCP 出口换了，浏览器和本地 DNS 仍把连接指向另一条目标路径。光盯着代理节点“在线”并不能证明整个请求链可达。

我在不同网络环境下看到的 DNS 解析结果和连接表现并不一致，于是考虑通过临时 hosts 规则验证，并调整代理的 DNS 路由策略。具体差异发生在权威 DNS、递归解析还是缓存环节，还需要靠抓包来区分。

相关原理：代理与 DNS 的职责边界、DNS 系统排查。不记录被访问的站点、真实出口 IP、节点地址或当前运行配置。

这篇只总结排查逻辑，源文件中的节点标识、IP、订阅和网络入口不放入 Blog。