V2ray SSH 连接正常但代理不可用的原因分析

过去半年，我身边至少有七位做虚拟币交易的朋友遇到过同一个诡异场景：SSH 能正常登录海外 VPS，ping 得通、curl 得动，但 V2ray 客户端就是连不上，代理状态一片红。更巧的是，这些人大多在行情剧烈波动时才发现问题——比如美联储议息夜、某交易所突然拔网线、或者链上 Gas 费暴涨导致套利窗口只有几分钟的时候。代理一挂，行情面板刷不出来，挂单撤单全部卡死，损失按秒计算。这篇文章不打算写成教科书式的排障手册，而是想把“SSH 正常但 V2ray 代理不可用”这件事，放到虚拟币交易的真实语境里拆开来看。很多原因单独看是技术问题，叠加了交易所风控、链上拥堵、节点 IP 被标记这些因素之后，就变成了一个混合型故障。

先厘清一个常见误解：SSH 通不等于代理链路通

SSH 走的是 TCP 22 端口（或者你自定义的端口），V2ray 常见的 VMess、VLESS、Trojan 走的是 443、8443 或者随机高位端口。两者在协议栈上完全独立，防火墙规则、服务进程、监听地址、TLS 配置都是分开的。SSH 能连上，只能证明三件事：VPS 没宕机、公网 IP 可达、22 端口没有被封。它完全不能证明 443 端口开放、V2ray 进程活着、TLS 证书有效、或者入站配置正确。

我见过最典型的一个案例：某位朋友在币安合约爆仓后急着补保证金，发现代理连不上，SSH 上去一看，V2ray 进程确实在跑，但 ss -tlnp 显示它只监听了 127.0.0.1:10086，而不是 0.0.0.0:443。原因是他前一天改配置时把 listen 字段写成了本地回环，SSH 当然不受影响，但外部客户端永远连不进来。这种错误在行情平静时可能几天都发现不了，一旦需要紧急操作就致命。

进程存活不等于服务可用

systemd 显示 active (running) 只代表主进程没退出。V2ray 的入站、出站、路由、DNS 四个模块任何一个配置出错，进程照样活着，日志里却全是 failed to dial 或者 context deadline exceeded。虚拟币交易者常犯的一个错是：为了低延迟，把出站 freedom 的 domainStrategy 设成 UseIP，结果 DNS 解析在 VPS 本地被污染，连交易所 API 域名都解析到错误 IP，代理自然不可用。SSH 用的是 IP 直连，完全绕过了这个坑，所以给人“服务器没问题”的错觉。

虚拟币热点下的五类高发原因

1. IP 被交易所或 Cloudflare 风控标记

这是近两年最隐蔽也最频繁的原因。很多交易者图便宜，买的是被反复转售的“原生 IP”VPS，实际上这些 IP 段早就被币安、OKX、Bybit 的 Cloudflare 防护层标记为高风险。表现是：SSH 正常，V2ray 握手也成功，但一访问交易所网页就 403 或者无限验证码，API 请求返回 451 或 1020。用户以为是代理坏了，其实是目标站点在拒绝这个出口 IP。

判断方法很简单：SSH 上去执行 curl -I https://www.binance.com，如果返回 403 而 curl -I https://www.google.com 正常，基本可以锁定是 IP 被目标站风控。去年某次大行情期间，大量交易者涌入同一批廉价 VPS 抢挂单，导致整个 C 段 IP 被交易所批量拉黑，那几天相关论坛上全是“V2ray 突然不能用”的帖子，实际原因跟 V2ray 一点关系都没有。

2. TLS 证书与 SNI 配置错位

Trojan 和 VLESS+WS+TLS 方案里，证书域名、SNI、Host 头三者必须一致。虚拟币圈流行一种“伪装成交易所域名”的玩法，把 SNI 设成 www.binance.com 来蹭白名单，但证书却是自己域名的自签或 Let's Encrypt 证书。浏览器和 V2ray 客户端对证书校验的严格程度不同，客户端可能静默失败，日志里只留下一行 tls: bad certificate。SSH 不涉及 TLS，所以完全感知不到。

更麻烦的是证书自动续期失败。Let's Encrypt 的 90 天证书如果因为 80 端口被占用或者 DNS 验证失败没续上，V2ray 进程不会退出，但所有 TLS 入站全部失效。很多交易者把 VPS 当纯代理机用，根本不开 80 端口，certbot 的 HTTP-01 验证自然过不了。等证书过期那天，代理突然全挂，SSH 却一切正常。

3. 出站路由被链上拥堵拖垮

这个原因听起来有点绕，但确实存在。部分交易者会在 VPS 上跑轻节点或者链上监控脚本，出站流量里混入了大量 RPC 请求。当以太坊或 Solana 网络拥堵时，这些 RPC 请求超时重试，把 V2ray 的出站连接池占满。V2ray 默认的 concurrency 和连接超时设置如果不合理，新进来的代理请求就会排队等待，表现为“连上了但没速度”或者“握手成功但网页打不开”。SSH 是独立会话，不受连接池影响。

我自己的做法是把链上监控和代理完全隔离到两个出站标签，给代理出站单独设 maxConcurrency，并且用 routing 规则把交易所 API 域名强制走直连或者独立出口。这样即使链上脚本把某个出站打满，代理主链路也不受影响。

4. 防火墙与云厂商安全组的“半开”状态

SSH 能通但代理不通，很常见的一个原因是云厂商安全组只开了 22 端口，443 端口没放行。用户在本机 ufw 或 iptables 里开了 443，却忘了云控制台的安全组是另一层。这种“半开”状态在 Oracle Cloud 和部分低价 VPS 商家那里尤其常见。虚拟币交易者换 VPS 频繁，每次迁移都容易漏配。

还有一种更阴的情况：某些地区的 ISP 对 443 端口做 QoS 限速或者 SNI 阻断，SSH 的 22 端口不在打击范围内。表现是 TCP 握手能完成，但 TLS 握手阶段被重置。用 tcpdump 在 VPS 上抓包能看到 SYN 到达、SYN-ACK 发出，但客户端侧收到 RST。这种问题换端口（比如 8443 或 2053）往往能临时缓解。

5. 客户端本地路由与 TUN 模式冲突

这一条跟 VPS 无关，但排查时最容易被忽略。虚拟币交易者常同时开多个工具：交易所客户端、链上钱包、行情软件、还有 V2ray 客户端。Windows 上某些钱包软件会安装 TUN/TAP 虚拟网卡，或者修改系统路由表，把默认路由抢过去。V2ray 客户端如果跑在系统代理模式，流量根本没进 V2ray；如果跑在 TUN 模式，又可能和钱包的虚拟网卡冲突，导致代理网卡起不来。SSH 走的是系统原生 TCP 栈，不受这些虚拟网卡影响，所以测试时一切正常。

排查方法：在代理不可用时，立刻在客户端侧执行 tracert 或 mtr 看流量走向，同时检查 route print 里默认路由指向哪块网卡。我遇到过一位朋友，装了某链上加速器之后，V2ray 的 TUN 网卡被挤到路由表末尾，所有流量走了加速器的透明代理，而那个加速器刚好在那天挂了。他以为是 V2ray 的问题，折腾了一晚上 VPS 配置。

一套面向交易场景的快速定位流程

行情不等人，排障流程必须能在三分钟内给出方向。我习惯按下面这个顺序走，每一步都对应一个明确的判断分支：

第一步：区分“链路不通”和“目标拒绝”

SSH 登录 VPS，执行 curl -x socks5://127.0.0.1:1080 -I https://www.google.com（端口按实际入站改）。如果 Google 通，说明 V2ray 服务本身正常，问题在目标站点或客户端；如果不通，问题在 VPS 侧。这一步能把排查范围砍掉一半。

第二步：看日志而不是猜

journalctl -u v2ray -n 100 --no-pager 或者 tail -f /var/log/v2ray/error.log。重点找 failed to dial、tls handshake failed、rejected 这几类关键词。虚拟币交易者容易犯的错是只看客户端 UI 的红绿状态，不看服务端日志。客户端显示“已连接”但实际流量没出去的情况太常见了。

第三步：用交易所域名做定向测试

分别 curl 三个目标：Google（测试基础连通）、币安 API（测试交易所风控）、一个普通 HTTPS 站点（测试 TLS）。三者结果组合能快速定位是 IP 被标记、TLS 配置错误还是全局出站故障。这个方法比逐个改配置快得多。

第四步：核对时间与证书

date -u 看 VPS 时间是否准确，时间偏差超过几分钟会导致 TLS 握手失败。再用 openssl s_client -connect 你的域名:443 -servername 你的域名 看证书有效期和链是否完整。证书过期是“SSH 正常但代理全挂”的经典原因，尤其常见于那些半年没登录过的备用机。

把排障前置到选型和配置阶段

与其等行情来了手忙脚乱，不如在平时就把几个坑填掉。选 VPS 时优先选 IP 干净、支持自定义 rDNS 的商家，别贪便宜买那种被大量代理用户轮番使用的 IP 段。配置上把 V2ray 的入站监听明确写成 0.0.0.0，出站给代理单独建标签并限制并发，路由规则里把交易所域名和链上 RPC 域名分流。证书续期用 DNS-01 验证，避免依赖 80 端口。客户端侧定期检查路由表和虚拟网卡，别让钱包软件悄悄改了默认路由。

还有一点值得单独提：准备一条 SSH 隧道作为应急通道。在 V2ray 完全不可用而 SSH 正常时，用 ssh -D 1080 开一个临时 SOCKS 代理，足够撑到你把行情单子处理完。这个技巧在几次大行情里救过我和朋友的急，成本为零，但前提是你得提前知道 SSH 还能这么用。

说到底，“SSH 正常但代理不可用”之所以让人抓狂，是因为它打破了“服务器活着就等于服务活着”的直觉。在虚拟币交易这个对延迟和可用性极度敏感的場景里，这种直觉偏差的代价往往直接体现在账户余额上。把 SSH 连通性只当作最底层的健康检查，把 V2ray 的入站、出站、路由、DNS、证书各自当成独立环节去验证，才能真正缩短从“发现挂了”到“恢复可用”的时间窗口。