@
wzxjohn 恩,你的应该是对的。当时我是觉得 https_proxy 代理设置应该是可以的,但是不知道死活不知道为什么不可以,然后就接受现实了。
我当初怀疑是 https 连接的问题,接连尝试了 google , Facebook , github ,都是 curl: (35) Server aborted the SSL handshake 。
而和百度一样,国内 V2EX 是可行。
所以自以为得出了一个 https 无法使用 socks5 的结论,我对网络请求协议了解不多,恩,我承认是弱鸡……
我当时单纯觉得,中间层转发 https 和直接 socks5 ,发出的请求应该都通过 ss 转发,如果有问题就应该都有问题。所以更倾向于是 socks5 和 https_proxy 之间有问题。
中途还尝试过 curl --socks5-hostname 127.0.0.1:1080
https://www.google.com ,可行,又觉得更符合自己的观察结果。
直接 https_proxy 出现问题的描述
all_proxy=socks5://127.0.0.1:1080 curl -ivvv
https://www.google.com * Rebuilt URL to:
https://www.google.com/* Trying 127.0.0.1...
* 93
* 46
* 8
* 89
* Connected to 127.0.0.1 (127.0.0.1) port 1080 (#0)
* Server aborted the SSL handshake
* Closing connection 0
curl 使用 socks5 代理的结果
curl -ivvv --socks5-hostname 127.0.0.1:1080
https://www.google.com* Rebuilt URL to:
https://www.google.com/* Trying 127.0.0.1...
* Connected to 127.0.0.1 (127.0.0.1) port 1080 (#0)
* TLS 1.2 connection using TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
* Server certificate:
www.google.com* Server certificate: Google Internet Authority G2
* Server certificate: GeoTrust Global CA
> GET / HTTP/1.1
> Host:
www.google.com> User-Agent: curl/7.43.0
根据上面的返回,我个人感觉也不太像 DNS 污染,这方面不了解…………
理由就像上面说的一样,我的 https 转发端口,其实也就是把本地监听了一个 https 端口,然后把数据传输到 SS 的 socks5 端口里面吧。
curl 这个方法我也不知道,是当时检查 proxy 是否起效,才找了这么个方法……更别说里面那一堆参数了。
其实,如果能有个 https 的
http://ip.cn/,我当初就能很快知道是不是起效了。不过就算是 DNS 污染, lz 的场景,我感觉还是用我这个比较简单点,毕竟每个 DNS 都加一遍,好麻烦。