节点被墙怎么办：先判断，再动手
被墙的最佳实践可以概括为一句话：先确认是不是真的被墙，再按入口、中转、落地分层定位，最后才决定换 IP、换端口还是调整架构。很多运营者看到用户反馈“全部节点连不上”就立刻换 IP，结果换完几天又失效，或者根本不是封锁，而是证书过期、配置写错、某个运营商线路抖动。
典型的被墙表现有几个特征：国内多个地区、多个运营商同时连接超时，而海外服务器或海外探测点访问同一 IP 和端口完全正常；国内 ping 不通但海外 ping 正常，通常指向 IP 级封锁；ping 正常但 443 等端口握手失败，更可能是端口或特征层面的干扰。如果海外访问同样失败，那基本可以排除封锁，应优先回到服务端配置和进程状态检查。直接判断的关键在于“国内外对比”，没有对比的结论都不可靠。
区分封锁、配置错误与普通网络问题
三类问题的处理方式完全不同，混在一起处理只会浪费 IP 和时间。可以按“看到 A → 判断 B → 下一步 C”的逻辑来分：
看到国内全网超时、海外探测正常，且换端口或换 IP 后能短暂恢复 → 判断为封锁 → 记录失效时间和入口 IP，进入分层定位，不要急着批量更换。看到海外也连不上，服务端日志出现 failed to read request header、证书错误或进程反复重启 → 判断为配置或服务端故障 → 检查配置文件、证书和服务状态。看到只有某一个运营商或某个时段（如晚高峰）出问题，mtr 结果显示中间某几跳持续丢包 → 判断为线路质量问题 → 考虑优化线路或增加中转，而不是当作被墙处理。
还有一种容易误判的情况：只有个别用户连不上，其他用户正常。这通常是客户端问题，例如订阅未更新、系统时间偏差过大、客户端内核版本过旧，应引导用户自查，而不是动服务端。
DNS、SNI、TLS 与客户端服务端单节点排查步骤
对单个疑似失效的节点，建议按以下顺序逐层排查，每一步都在国内和海外各执行一次：
1. 检查 DNS：执行 dig example.com 或 nslookup example.com，对比国内外解析结果。国内返回的 IP 与真实 IP 不一致或明显异常，说明域名可能遭到污染。 2. 检查端口连通：用 nc -vz 目标IP 443 或 tcping 测试。海外通、国内不通，指向 IP 或端口封锁。 3. 检查 TLS 与 SNI：执行 openssl s_client -connect 目标IP:443 -servername example.com。国内握手被重置而海外正常，可能是基于 SNI 或 TLS 特征的干扰；换一个 SNI 测试有助于缩小范围。 4. 检查服务端：ss -tlnp 确认端口在监听，journalctl -u xray -n 100 查看近期日志，openssl x509 -enddate -noout -in 证书路径 检查证书是否过期。 5. 检查客户端：确认 UUID、传输方式、路径与服务端一致；使用 VMess 时系统时间误差需控制在 90 秒内；更新订阅和客户端内核后重试。
前四步全部正常而只有部分用户失败，问题大概率在客户端侧。
处理之后如何验证：按层复测，而不是只看“能连上”
换 IP、改端口或调整 SNI 之后，不要只用一台手机打开网页就判定恢复，偶然成功很容易被当成已经修好。建议在国内多个运营商网络各取一个测试点，按层复测。第一步，用 tcping 或 nc -vz 203.0.113.10 443 确认 TCP 能稳定建立。第二步，用 openssl s_client -connect 203.0.113.10:443 -servername cdn.example.com 观察握手是否完成、证书链是否正确。第三步，在客户端开启详细日志，确认流量是否真正到达落地。
结果按下面的逻辑判断。TCP 能通，但握手阶段反复出现 connection reset 或超时，问题多半在 SNI、TLS 特征或端口层面，应回到协议参数检查。入口握手成功，中转却没有对应的连接记录，说明转发规则或中转链路有问题。落地日志里有连接，客户端仍然超时，应检查落地出口和回程路由，可以配合 mtr 分析。复测建议持续 24 到 72 小时，并且覆盖晚高峰。只在单一时段、单一网络测试正常，不能算作恢复。
失败边界：哪些情况说明临时手段已经不够
换 IP、改端口、更换伪装域名都属于低成本手段。它们能暂时绕开当前被识别的入口，但不会改变链路的暴露方式。出现下面几种信号时，应停止单纯重复这些操作：
- 新 IP 上线后几小时到几天内又出现同样的 TCP 阻断或握手重置，而且多次都是这个节奏。 - 多个入口同时失效，并且它们共用同一网段、同一中转或同一落地。 - 订阅内容或面板接口直接暴露了落地 IP，换掉入口后整条链路仍然很快被关联。
还有一些情况不在运营者的控制范围内，比如特定时期大范围的运营商策略调整，或某个地区整体丢包。这时继续改配置只会增加排查噪音。更稳妥的做法是先记录现象，包括失效时间、受影响的运营商、入口列表和对应日志，据此区分单点问题和结构性问题，再决定下一步投入。任何调整都无法让单个入口一直不被识别，合理的目标是缩小影响范围、缩短失效后的恢复时间。
长期架构与服务适用边界
如果入口反复失效，更实际的做法是把入口、转发和后端解耦，可以按以下顺序落地：
1. 入口层使用多个运营商、多个网段的地址，只负责接入，可以随时替换。 2. 中转层把流量分发到不同落地，避免一个入口直接连到源站。 3. 落地地址不写进订阅，管理端口只对白名单开放，降低源站暴露风险。 4. 定时对入口做 TCP 和 TLS 探测。握手连续失败超过设定阈值时，把该入口从订阅下线，并换入备用入口。 5. 使用 XBoard 或 V2Board 时，确认节点地址和参数支持批量更新，避免切换速度被人工操作拖慢。
如果只是单个节点证书过期、端口写错或客户端版本不兼容，按前文步骤自查即可。如果多个入口或中转频繁失效，换 IP 后短期内反复出现问题，或者需要区分入口、中转与落地故障并设计切换方案，可以参考 Manguo Labs 的机场高可用入口解决方案（https://manguolabs.com/node-firewall/）。这套方案侧重入口、中转与落地链路的高可用规划和故障排查。实际效果取决于线路资源和运营环境，建议先整理现有拓扑和失效记录，再评估是否适用。
什么时候这已经不是单点配置问题
如果按上面的步骤排查后，确认问题只出在单个节点的配置上，自己修复就够了。如果多个入口或中转反复失效、换 IP 后很快又不可用，问题已经不在单个节点，而在整体架构，这时可以参考成熟的入口高可用规划思路来设计切换方案。
Manguo Labs 能提供什么
Manguo Labs 为机场运营者提供入口、中转与落地链路的高可用规划和故障排查方案。
本文对应的需求是：机场运营者在单个节点修补之外，需要做入口、中转、落地的分层定位和切换设计。Manguo Labs 的机场高可用入口解决方案提供入口、中转与落地链路的高可用规划和故障排查，适合多个入口或中转频繁失效、换 IP 后短期内反复出现问题的场景。
适合这些情况
- 多个入口或中转频繁失效的机场运营者
- 换 IP 后短期内又反复失效、需要找到根因的团队
- 需要区分入口、中转与落地故障并设计切换方案的场景
常见问题
怎么快速判断节点是被墙了，还是配置出了问题？
分别从国内和境外对同一个 IP 和端口做 TCP 探测，例如 nc -vz IP 443。如果境外能连、国内超时，较可能是封锁；如果境内外都不通，就去服务端查进程、端口监听和防火墙；如果 TCP 能连但客户端报 TLS 握手失败，重点检查 SNI、证书和协议参数是否一致。
只封了端口，和整个 IP 被封，表现有什么区别？
只封端口时，同一个 IP 上的其他端口在国内仍能 TCP 连通，换一个端口通常就能临时恢复；整个 IP 被封时，国内对所有端口都超时，ping 往往也不通。可以在服务器上临时开一个测试端口，从国内探测来做对比。
为什么换了 IP 没多久又被墙？
常见原因有：入口直接暴露了源站或落地机；协议特征和流量模式没有变化；新 IP 和旧 IP 在同一网段或同一服务商下；订阅里的入口地址被大范围分发。只换 IP 不改这些条件，失效往往会再次出现。
有中转的线路，怎么判断是哪一层出了问题？
先从国内测入口端口，再在入口机上测到中转的连通性，然后在中转机上测到落地的连通性。按顺序逐段测，哪一段开始不通，问题就在哪一层。如果国内到入口就已经超时，优先处理入口；如果入口到中转正常、到落地失败，就检查落地机和它的防火墙。
什么情况下需要考虑高可用入口方案？
如果多个入口或中转频繁失效、换 IP 后短期内反复出现问题，或者需要清楚区分入口、中转、落地故障并设计切换方案，单个节点的修补就不太够了，这时可以评估入口、转发、后端解耦的整体架构。
总结与下一步
被墙最佳实践的核心是三步：先用境内外对比探测确认是封锁、配置还是网络问题；再依次检查 DNS、SNI/TLS、客户端和服务端，按入口、中转、落地分层定位；最后承认换 IP、换端口只是临时手段，长期需要把入口、转发和后端解耦，减少源站暴露，并准备多线路切换。这样做没法保证不再被墙，但能缩小影响范围、缩短恢复时间。
需要进一步评估时，可先查看机场高可用入口解决方案，并参考更多技术文章。
继续阅读
了解 机场高可用入口解决方案 →