V2ray WebSocket 伪装 HTTPS 流量实现方法

过去两年，虚拟币市场的波动让“链上数据自由”成了刚需。无论是追踪 Solana 上新币的流动性池，还是凌晨三点抢跑以太坊的 NFT 铸造，网络延迟和区域限制往往比 Gas 费更让人头疼。我身边不少做量化交易和空投猎人的朋友，都在用 V2ray 的 WebSocket + TLS 方案把代理流量伪装成普通 HTTPS 请求，从而在交易所 API 调用、链上浏览器访问和社区信息同步之间找到平衡。这篇文章不聊价格预测，只拆解这套伪装方案的技术细节，以及它在虚拟币场景下踩过的坑。

为什么虚拟币玩家偏爱 WebSocket 伪装

虚拟币活动对网络有两个硬要求：低延迟和抗封锁。传统 VMess over TCP 在跨境链上交互时容易触发 QoS 限速，而 WebSocket 走的是标准 HTTP/1.1 升级握手，配合 TLS 后与普通网页流量几乎无异。更重要的是，WebSocket 支持全双工通信，对于需要长连接的行情推送、mempool 监听和 Telegram 机器人回调来说，比轮询方式节省大量握手开销。

另一个现实原因是 CDN 兼容性。很多虚拟币项目方的前端部署在 Cloudflare 上，而 V2ray 的 WS 模式天然适合套 CDN——你只需要一个域名和一张证书，就能让代理流量混在正常的 Web 请求里穿过边缘节点。对于需要频繁切换 IP 的撸空投工作室来说，这种“看起来像在访问普通网站”的特性比单纯的加密更重要。

与虚拟币热点的具体交集

举几个我实际遇到过的场景：某次 BRC-20 代币 mint 期间，项目方前端被打了 Cloudflare 五秒盾，直连钱包插件根本加载不出合约交互页面，但通过 WS+TLS 代理走同一个 CDN 的另一个域名却畅通无阻；再比如追踪 Base 链上的土狗合约时，需要同时开着区块浏览器、DEX 聚合器和社群监控，WS 多路复用让浏览器并发连接数不再成为瓶颈。这些需求催生了对“稳定且隐蔽”的代理方案的持续投入。

核心架构：从客户端到 CDN 的完整链路

整个方案可以拆成四层：客户端 V2ray → CDN 边缘节点 → 源站 Nginx → V2ray 服务端。每一层都有需要留意的细节，尤其是和虚拟币工具链配合时。

域名与证书：伪装的第一道门面

别用明显带“proxy”“vpn”字样的子域名。我的习惯是拿一个和虚拟币资讯相关的普通域名，比如 data-node.example.com 或 api-gateway.example.com，证书用 Let's Encrypt 免费签。Cloudflare 开启“完全（严格）”SSL 模式，源站也配同一张证书，这样 CDN 到源站之间也是加密的。注意：如果你用 Cloudflare 的代理模式（橙色云朵），WebSocket 默认是开启的，不需要额外配置，但要把“网络”里的 WebSocket 开关确认打开。

Nginx 反向代理的关键配置

源站 Nginx 需要把特定路径的请求转发给 V2ray 的 WS 监听端口。下面是我在 Ubuntu 22.04 上用的片段，路径故意设成 /ws-market-data 这种看起来像行情接口的名字：

location /ws-market-data {     proxy_pass http://127.0.0.1:10000;     proxy_http_version 1.1;     proxy_set_header Upgrade $http_upgrade;     proxy_set_header Connection "upgrade";     proxy_set_header Host $host;     proxy_set_header X-Real-IP $remote_addr;     proxy_read_timeout 3600s;     proxy_send_timeout 3600s; } 

这里有个和虚拟币场景强相关的细节：proxy_read_timeout 要设得足够长。链上数据推送往往有静默期，如果超时太短，连接会被 Nginx 切断，导致你的监控脚本误判为节点掉线。我一般设 3600 秒，配合 V2ray 的 heartbeat 保活。

V2ray 服务端与客户端配置拆解

服务端 inbound 用 VMess 或 VLESS 都行，VLESS 更轻量，但如果你需要动态端口或多用户管理，VMess 的生态工具更成熟。下面以 VLESS + WS + TLS 为例。

服务端 inbound 配置

{   "inbounds": [{     "port": 10000,     "listen": "127.0.0.1",     "protocol": "vless",     "settings": {       "clients": [{"id": "你的UUID", "level": 0}],       "decryption": "none"     },     "streamSettings": {       "network": "ws",       "wsSettings": {"path": "/ws-market-data"}     }   }] } 

注意 listen 只绑本地回环，外面由 Nginx 兜底。UUID 别用在线生成器，本地 v2ray uuid 命令生成即可。虚拟币圈子里流传过“UUID 泄露导致节点被白嫖跑链上脚本”的案例，本质是配置管理疏忽。

客户端 outbound 与路由规则

客户端这边，WS 的 path 必须和服务端一致，Host 头填你的域名。TLS 的 serverName 也填域名，allowInsecure 一定设为 false。路由规则里可以针对虚拟币相关域名做分流：比如把 api.binance.com、mainnet.infura.io、rpc.ankr.com 走代理，而本地交易所的局域网 API 直连。这样既降低延迟，又避免所有流量都挤在一条 WS 连接上。

"routing": {   "rules": [     {"type": "field", "domain": ["geosite:binance", "geosite:coinbase"], "outboundTag": "proxy"},     {"type": "field", "domain": ["geosite:category-games"], "outboundTag": "direct"}   ] } 

geo 规则文件要定期更新，新上线的 DEX 域名可能不在旧列表里，手动加进去更稳妥。

虚拟币实战中的性能调优与踩坑记录

配置跑通只是第一步，真正影响体验的是下面这些细节。

CDN 缓存与 WebSocket 的冲突

Cloudflare 默认对 WebSocket 不做缓存，但如果你在页面规则里误开了“缓存所有内容”，WS 升级请求可能被缓存层拦截，表现为客户端反复重连。虚拟币项目方的前端经常用 Cloudflare 的“缓存 HTML”规则，代理域名千万别照抄。另一个坑是 CDN 的 100 秒空闲超时：某些免费套餐会在连接空闲 100 秒后断开，而链上监听脚本可能几分钟才有一条消息。解决办法是在 V2ray 的 wsSettings 里加 "heartbeatPeriod": 30，让客户端每 30 秒发一个空帧保活。

MTU 与链上 RPC 大响应

调用以太坊归档节点查历史日志时，响应体可能达到几 MB。WS 分片传输下，如果 MTU 设置不当，会出现“小请求正常、大响应卡死”的现象。把客户端和服务端的 tcpMtu 显式设为 1400 左右，或者干脆在 Nginx 里调大 proxy_buffer_size，能缓解这个问题。我曾在追踪一个 MEV 机器人交易时被这个坑了半小时，最后发现是 Nginx 默认 4KB 缓冲区装不下 RPC 返回的 trace 数据。

多节点负载与空投工作室的并发

如果你像某些空投猎人一样同时跑几十个钱包交互，单条 WS 连接会成为瓶颈。V2ray 的 mux 多路复用可以缓解，但开启后对 CDN 的兼容性要求更高。更稳的做法是部署多个子域名指向同一源站的不同路径，客户端用 balancers 做负载均衡。注意每个子域名都要单独签证书，Let's Encrypt 的通配符证书在这里很实用。

安全边界：伪装不是免死金牌

WS+TLS 能骗过基于 SNI 和流量特征的被动检测，但对主动探测无能为力。如果你的域名被墙了主动扫描，返回的 HTTP 响应必须和正常网站一致——这就是为什么源站最好真放一个静态页面，比如一个假的“行情数据 API 文档”，访问根路径时返回 200 和正常 HTML。虚拟币圈子里有人用 Flask 写了个假 K 线图页面做掩护，成本极低但效果不错。

另外，别在同一个 IP 上混用代理和挖矿节点。某些云厂商会对高流量 WS 连接做深度包检测，而虚拟币矿池的 Stratum 协议特征明显，混在一起容易触发风控。分开机器部署，代理走 CDN，矿机走独立出口，这是基本纪律。

替代方案对比：什么时候不该用 WS

如果你主要用手机钱包 App 做链上交互，gRPC 传输可能比 WS 更省电；如果是纯浏览器环境访问 DEX，HTTP/2 的 multiplexing 已经够用，WS 的额外握手反而增加延迟。WS 伪装最适合的场景是：需要长期稳定长连接、目标服务对 CDN 友好、且你愿意维护域名和证书。对于偶尔查个余额的普通用户，直接买个商业 VPN 更省事——但如果你要跑自动化脚本、管理多链 RPC 端点，这套方案的可控性是商业服务给不了的。

最后提醒一句：虚拟币领域的网络工具更新极快，V2ray 核心虽然稳定，但周边生态（比如 geo 文件、CDN 策略）几个月就变。保持配置版本化管理，用 Git 记录每次改动，出问题时能快速回滚——这比任何“一键脚本”都可靠。