飘在云端

啊!那蓝真天,白真云!

· 备查 · · 141次浏览

curl: (35) OpenSSL SSL_connect: Connection reset by peer in connection xxx

网上资料很多都是 TLS 协议太旧、库版本太旧被放弃支持,问题是现在都什么年代了,实际遇到的问题都不是这些

有没有一个可能是要访问的域名被 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 

随手 ping 一下这个域名,返回了一个被 污染的结果:59.24.3.174
进一步检查,可以看到在国内的许多 POP 解析测试节点上都被污染,除了深圳地区有幸逃过一劫,国内全部污染,国外访问均正确解析到了 Cloudflare
请输入图片描述

解决办法很简单:一个是换域名,修改前后端应用的 被污染域名至新域名,但是还可能被再次污染

我这里使用了其他方案

本地架设一台 科学上网客户端,客户端使用专线代理数据,并在本地开放 一个 socks5 的端口方便 curl 调用

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

先修改默认 curl 调用参数

vim /etc/profile

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

source /etc/profile

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

评论 (0条)