Home - ShioMile/Pixiv-Nginx GitHub Wiki

Pixiv-Nginx 说明书

前言

自2018年8月起，防火长城（Great Fire Wall, GFW）封锁升级，包括Pixiv、维基百科在内的常见境外网站，由域名服务器缓存污染（DNS cache pollution, 简称 DNS污染，又名 DNS投毒/DNS cache poisoning）升级到基于服务器名称指示（Server Name Indication, SNI）检测的TCP重置攻击（TCP reset attack, RST）。

通过Hosts文件进行本地域名解析的访问方式在上述网站中失效。

原理

现行的TLS协议中，客户端与服务器必须通过7次握手（Handshake）才能建立加密连接，而在第1次握手即ClientHello中，向服务器发送的SNI是明文的，因此GFW很轻易地探测到用户所访问的网站域名，通过向客户端和服务器同时发送Reset（重置）包，使连接双方都认为对方关闭了连接，从而阻断加密连接的建立。

目前DNS污染仍是GFW封锁网站主要手段，被SNI-RST的网站一般保留DNS污染的封锁方式（浏览器提示连接超时），而尝试通过向Hosts文件写入正确IP进行本地域名解析后，Chromium系浏览器会立即显示连接已被重置、ERR_CONNECTION_RESET，Firefox则是建立安全连接失败、PR_CONNECT_RESET_ERROR。

TCP-Reset Attack by GFW

本项目使用常见的Nginx反向代理配置修改而来。Nginx反代配置中ClientHello默认不发送SNI，即proxy_ssl_server_name默认为 off）。大部分网站因兼容不支持SNI的旧版浏览器需要，允许无SNI访问网站，从而绕过封锁。理论上支持所有遭SNI RST封锁的网站。

Tip: 快速查询网站是否被SNI-RST（点击展开）

通过反复写入Hosts文件来观察浏览器错误代码来验证网站是否SNI-RST的方法又蠢又麻烦（且Hosts不一定立即生效，有时甚至需要重启设备），因此可使用cURL命令（Win10已自带，版本较旧）可快速查询网站是否被SNI-RST：

curl -H "Host:<域名>" --resolve <域名>:443:<IP> https://<域名>

<域名>处填网址，<IP>处填写正确IP（由第三方IP查询网站获得），当显示错误curl: (35) failed to receive handshake, SSL/TLS connection failed则表示该网站已被SNI-RST。

此为Win10自带的cURL v7.55.1的所输出的错误提示，新版则为curl: (35) OpenSSL SSL_connect: Connection was reset in connection to <域名>:443（如上图所示）。

使用方法

Windows	\|	Android

常见问题

目前支持的网站

无法支持的网站

大量使用Cloudflare及Amazon CloudFront的CDN网站由于其特性必须指定SNI才能访问，因而无法支持。可通过两种方法查询：

方法一：使用OPENSSL命令

openssl s_client -connect <域名>:443 -noservername -proxy 127.0.0.1:1080

openssl s_client -connect <域名>:443 -servername <域名> -proxy 127.0.0.1:1080

输入上述两项命令，比对输出结果（比如输出结果长度、有无报错、证书是否一致等）。若结果不一致，则表明服务器要求客户端/浏览器必须发送SNI。

127.0.0.1:1080为Shadowsocks的默认本地端口，若使用其它代理软件如Tor、I2P等请自行修改端口号。

方法二：使用SSLlabs进行检测

SSLlabs是用来检测网站SSL加密强度等全方位检测的网站并给予评分，其中一项Handshake Simulation检测便是模拟各种设备/浏览器访问网站，包括不支持SNI的设备/浏览器。必须指定SNI的网站会标识：This site works only in browsers with SNI support（该网站仅在具有SNI支持的浏览器中可访问）。虽然方法较笨但可读性强非常直观。

案例（点击展开）

apkmirror.com（Cloudflare），无需SNI。

Cloudflare_apkmirror_com

matters.news(CloudFront)，必须指定SNI。

Cloudfront_maters_news

返回首页