网上查找资料部分原因是 TLS 协议太旧、库版本太旧被放弃支持，问题是现在都什么年代了，更何况我是在用 ubuntu 20.04.03，也一直保持最新的软件包和内核，实际遇到的问题都不是这些库、协议太旧的原因

有没有一个可能是要访问的域名被 DNS 污染，RST 重置、SNI 间歇阻断？

因为最近要开大会了......

---

今天某个后台应用在调用某个 API 出现了异常
它需要调用一个接口： https://data.xxxx.sh/v2.6/auth/?sing=akdgloapdgjoa&text=xxxxxxx

巧的是，接口后端访问做了负载均衡，在境内外都部署了服务器，加速访问请求和简单冗余灾备
调试期间，关闭了负载均衡，当请求到了境外 DNS 解析到的 服务端IP后，又没有这个问题

当境内去解析这个域名时，抛出异常，手动 curl 访问该接口，返回

curl: (35) OpenSSL SSL_connect: Connection reset by peer in connection to data.xxxx.sh:443 

使用当前异常的Linux环境 ping 一下这个域名，返回了一个被 污染的结果：59.24.3.174，莫名躺枪......，不死心，我的域名就这么完了？？

使用 https://ping.pe/ 进一步检查,可以看到在国内的许多 POP 解析测试节点上都被污染，除了深圳地区有幸逃过一劫，国内全部污染，国外访问均正确解析到了 Cloudflare

解决办法很简单：一个是换域名，修改前后端应用的 被污染域名至新域名，但是还可能被再次污染,且需要更改域名配置，不太方便

我这里使用了其他方案，本地使用代理客户端挂上一些稳定的机场的梯子，并在本地开放 一个 socks5 的端口方便 curl 调用

最后修改默认前后端的配置文件及相关 curl 参数

先修改默认 curl 调用参数 /etc/profile

新增一行 alias curl='curl -x socks5://127.0.0.1:1080'

source /etc/profile

生效后，直接 curl 访问接口，成功通过 socks5 远端 DNS 解析避免了污染，同时也代理了所有网络流量避免后续其他污染风险