Nginx SNI 分流（端口复用）使用Xray+VLESS+XTLS 前言 Xray已经出来一段时间了，之前一直使用VLESS+tls+ws方式科学上网，其实都够用，没什么问题。但是了解了下XTLS黑科技，再看看Xray性能测试，这货简直爆炸，性能是TLS的数倍。 其实之前折腾过一次，但是Xray要监听443端口（不监听也行，但是不完美啊），影响做站。虽然有解决方法，但是不够完整，我一不小心就跳坑里面去了。Xray已经带了SNI回落功能（教程看这里：通过 SNI 回落功能实现伪装与按域名分流），Nginx也带SNI功能，我还是觉得用Nginx的比较好，免得折腾Xray影响网站运行。 这里我不会写如何安装Xray，因为教程实在是太多了，嫌麻烦还有一键脚本：Xray_onekey（V2ray脚本别用这个作者的哈,特别是服务器有站点的！！！Xray脚本这个大佬的还不错）。 坑 因为服务器上有几个站点，装完Xray后实现SNI分流，过程非常顺利，但是chrome上有问题，几个二级域名访问的内容全部和第一个访问的域名一样。 例如：我先访问 a.example.com 然后在访问 b.example.com，b.example.com 响应内容和 a.example.com 一模一样，然后再访问 c.example.com 还是和 a.example.com 一样。开chrome隐身模式直接访问 c.example.com 正常，然后访问 a.example.com 或 b.example.com 内容又全是 c.example.com 的（不一定会每次都这样，要看浏览器是否使用现有连接或服务器是否断开了之前的连接）。 这个问题折腾我很长时间，最后发现和HTTP/2有关，我所有站点不使用HTTP/2就会正常，只要有一个站点使用了HTTP/2，你先访问HTTP/2站点，那么后面的其他子域名都会变成它的内容。这个情况没有仔细测试证明，无法确定。 最开始我使用Xray的SNI也是这样，我还以为是Xray SNI的问题，之后换成Nginx使用SNI还是这样。chrome中有这个问题，用手机safari浏览器完全正常。 经过网上一番搜刮，终于找到了问题根源：通配符域名证书。 首先你得了解什么是SNI，个人理解：SNI就是通过证书区分服务。多个二级域名使用通配符域名证书的话，相同的证书无法区分具体想访问的服务，因为它们的证书都一样。 用下人家的图（原作者文章：Multiplex TLS Traffic with SNI Routing）： *由于原始服务器10.0.3.2使用的TLS证书具有通配符名称 .example.com，因此Web浏览器可以建立服务器名称为 b.example.com 的 TLS连接，并对HTTP/2请求使用相同的连接到 a.example.com。这可能会在网站和应用程序中导致未定义的行为。** 因为HTTP/2会保持TCP连接，导致你访问了 a.example.com 后，在访问 b.example.com 的时候使用的同一个连接，SNI跟失效了一样，直接使用该连接访问之前的服务。我在Xray的调试日志中发现访问错误的域名没有获取到，是空的！ 两个域名使用同一个连接（红框内是连接ID），可以很清楚的看到两个域名使用同一个连接，返回的内容也是一模一样： 解决办法两种： 不使用HTTP/2。不确定是否HTTP2的问题，但是你可以试一试 不使用通配符域名证书，站点域名证书一个个申请。 配置Nginx SNI 使用Nginx首先得安装（如果服务器自带就不用折腾了），不会安装Nginx可以看我之前的文章：Ubuntu 安装nginx（如果使用Xray_onekey脚本，那他已经帮你全部弄好了，你都不用折腾）。 nginx.conf配置追加： stream { map $ssl_preread_server_name $orzlee { a.example.com a; b.example.com b; c.example.com c; } upstream a { server 127.0.0.1:60088; ### A站点监听端口，xray xtls伪装站点 } upstream xtls { server 127.0.0.1:4443; ### 你的Xray端口 } upstream b { server 127.0.0.1:60001; ### B站点监听端口，业务站点 } upstream c { server 127.0.0.1:60002; ### C站点监听端口，业务站点 } server { listen 443 reuseport; listen [::]:443 reuseport; proxy_pass $orzlee; ssl_preread on; proxy_protocol on; } server { ### Xray XTLS listen 127.0.0.1:60088 proxy_protocol; proxy_pass xtls; } } a.example.com.conf配置（伪装站点）: server { listen 80; listen [::]:80; server_name a.example.com; return 301 https://$http_host$request_uri; } server { ### 伪造站点由Xray处理SSL listen 127.0.0.1:60003 proxy_protocol; ### xray http/1.1 listen 127.0.0.1:60004 http2 proxy_protocol; ### xray http/2 set_real_ip_from 127.0.0.1; real_ip_header proxy_protocol; port_in_redirect off; ###重定向去掉端口号 server_name a.example.com; index index.html index.htm index.php default.php default.htm default.html; root /var/www/a.example.com; ... } b.example.com.conf配置（其他业务站点配置照葫芦画瓢）: server { listen 80; server_name b.example.com; rewrite ^(.*) https://b.example.com$1 permanent; } server { listen 127.0.0.1:60001 proxy_protocol ssl http2; set_real_ip_from 127.0.0.1; ### 获取真实客户IP，不然全是127.0.0.1 real_ip_header proxy_protocol; port_in_redirect off; ###重定向去掉端口号。不然类似 try_files nginx帮你重定向时，你浏览器上都带了60003这样的端口 ssl_certificate b.example.com.cer; ### 证书换成你的 ssl_certificate_key b.example.com.key; ### 证书换成你的 server_name b.example.com; root /var/www/b.example.com; index index.php index.html index.htm; ... } 配置Xray 服务端配置： { "log": { "access": "/var/log/xray/access.log", "error": "/var/log/xray/error.log", "loglevel": "warning" }, "inbounds": [ { "listen": "127.0.0.1", "port": 4443, "protocol": "vless", "settings": { "clients": [ { "id": "你的UUID", "flow": "xtls-rprx-direct" } ], "decryption": "none", "fallbacks": [ { "dest": 60003, "xver": 1 }, { "dest": 60004, "alpn": "h2", "xver": 1 } ] }, "streamSettings": { "network": "tcp", "security": "xtls", "xtlsSettings": { "alpn": [ "h2", "http/1.1" ], "minVersion": "1.3", "certificates": [ { "certificateFile": "b.example.com.cer 记得换证书", "keyFile": "b.example.com.key 记得换证书" } ] } }, "sniffing": { "enabled": true, "destOverride": [ "http", "tls" ] } } ], "outbounds": [ { "protocol": "freedom" } ] } 客户端看作者说明吧，值得一看：Outbounds 可用协议列表-VLESS，flow仔细看看。 结语 本来折腾Xray的，结果Nginx折腾大半天。虽然掉坑里了，总算是爬出来了，受益匪浅！ 通配符证书用起来省事，碰到坑了一下还不好找问题。就今天这个坑上网找都不知道怎么描述，基本上找不到相关问题，比较冷门。之前参考其他博主Nginx SNI配置发现有其他同学也有这样的问题，但是无从查起，不了了之！ 遇到这个坑不长记性都难。