国内直连海外 DNS 服务器，经常出现握手被 RST、查询超时、随机失败。本文讲清现象、判断、四种应对方案和地区选型。
国内访问海外 DNS 服务器的干扰，按端口严重程度排序：53 端口 UDP 明文 DNS 最严重（查询被丢弃、返回伪造响应）；853 端口 DoT 次之（TLS 握手被 RST）；443 端口 DoH 最隐蔽（与正常 HTTPS 流量同端口，RFC 8484）。判断方法：用 dig +tcp、nslookup、tcpdump 对比干净 DoH 结果。应对优先级：① 在国内 VPS 上自建加密 DNS（用户不跨境）→ ② 海外服务器跑 DoH 443 混淆 → ③ 国内中转机+隧道转发到海外 → ④ 备用多地区节点故障切换。选服务器地区：香港/日本求低延迟，新加坡求稳定，美国西海岸求隐私。
不是"网络不好"，而是链路层对特定端口的针对性阻断
发出去的 DNS 查询包收不到回复，反复重试均超时；但同一台服务器的 SSH/HTTPS 却正常。这是链路对 UDP 53 跨境包的典型丢弃行为。
DoT（RFC 7858）在 853 端口完成 TCP 握手后，ClientHello 发出后立刻收到 RST 包，连接被重置。
同一域名第一次解析成功，第二次返回错误 IP；或者时好时坏，重启路由器又恢复几小时。这是链路对特定域名/特征的间歇性注入。
发查询后立刻收到 ICMP 类型 3 代码 3（目标端口不可达），说明链路中间节点直接丢弃并回包，根本没到你的海外服务器。
不要凭感觉，用工具量化
dig @1.1.1.1 example.com 走普通链路curl -s 'https://cloudflare-dns.com/dns-query?name=example.com&type=A' -H 'accept: application/dns-json' 走 DoHsudo tcpdump -i any port 853 or port 53 -nnRST 包紧随 ClientHello，或 ICMP type=3 code=3dig +tcp @海外IP example.com -p 53 测 TCP 53kdig -t @海外IP example.com -p 853 测 DoTcurl -k https://海外IP/dns-query -d '...' 测 DoH从轻到重，从省钱到折腾
在国内阿里云/腾讯云轻量服务器上跑 AdGuard Home / unbound，对外暴露 DoH/DoT。国内用户访问国内 IP 完全不跨境，链路无干扰；上游再用 DoH 指向 Cloudflare。成本最低、稳定性最高。
在香港/日本服务器上用 Caddy / Nginx 反代 DoH 端点，走 443 端口，配一个正常域名 + Let's Encrypt 证书。链路看起来就是普通 HTTPS 网站流量，Cloudflare DoT/DoH 文档可作参考。
国内中转机用 iptables DNAT / Gost / FRP 把 443 端口流量转发到海外源站。用户连的是国内 IP，实际解析发生在海外。适合需要海外出口又不想自己搭 DoH 的场景。
同时维护香港、日本、新加坡三个 DoH 端点，本地用 systemd timer / healthcheck 脚本定时探测，哪个通就切哪个。DoQ（RFC 9250）基于 QUIC 走 UDP 853，可作为备用协议。
延迟、稳定性、内容自由度三难，按场景选
| 地区 | 典型延迟 | 稳定性 | 内容自由度 | 适合场景 |
|---|---|---|---|---|
| 香港 | 30~60ms | 中等（偶尔被针对性清理） | 高 | 追求低延迟、个人小流量、做国内中转入口 |
| 日本（东京/大阪） | 60~100ms | 高 | 高 | 稳定做 DoH/DoT 出口、长期运营节点 |
| 新加坡 | 120~180ms | 很高 | 高 | 亚太骨干节点、对稳定性要求极高的服务 |
| 美国西海岸 | 150~200ms | 很高 | 极高 | 隐私敏感、需要访问完整海外内容、不介意延迟 |
| 国内（阿里云/腾讯云） | 5~30ms | 极高 | 受国内法规约束 | 只解决国内用户访问稳定性，不作为隐私出口 |
经验建议：主力节点放日本/新加坡（稳），香港节点做国内中转入口，美国节点做隐私兜底。不要把鸡蛋全放在香港一个篮子里——香港 IP 段偶尔会被整体限流。