防墙如何排查：先判断是“被封”还是“故障”
防墙排查的第一步不是换 IP，而是先确认节点失效属于哪一类。可能是 IP 或端口被封锁，可能是协议特征被识别，也可能只是配置、证书、DNS 或线路出了问题。判断标准很直接：国内多地探测全部超时，海外探测正常，服务端进程和端口监听也都在，这时才比较可能是封锁。只要海外同样连不上，或者服务端日志有报错，就应该先按配置或服务故障处理。
用户侧的现象大致分三类。第一类是所有节点同时不可用，多半是订阅、客户端或本地网络的问题。第二类是某个入口突然全线超时，换手机流量、换宽带后依旧连不上，偏向入口 IP 被阻断。第三类是能连上，但速度骤降、间歇断流或 TLS 握手失败，常见原因有端口被干扰、SNI 特征被识别，或者中转链路拥塞。先按现象归类，再进入分层排查，可以避免“换了 IP 才发现是证书过期”这类白费的操作。
区分封锁、配置与网络问题：看到什么，判断什么
区分三类问题，关键是同时对比“国内与海外”“ICMP 与 TCP”“握手前与握手后”这几组结果。
看到国内 ping 和 TCP 端口都不通，海外两者都正常，可以判断 IP 级阻断的可能性较大，下一步用多个地区、多个运营商的探测确认，再决定是否切换入口。看到 ping 正常，但指定端口 TCP 超时，换端口后恢复，说明更可能是端口级封锁或干扰，下一步记录端口和发生时间，不要在原端口上反复复用。看到 TCP 能建立，但客户端日志出现 connection reset by peer 或 TLS handshake timeout，就要看海外是否也能复现。海外也复现，多为证书、SNI 或协议参数不一致，属于配置问题；只有国内复现，则要考虑协议或 SNI 特征被识别。
看到海外同样连不上，问题在服务端或机房网络，应检查进程、本机防火墙和云厂商安全组。如果只是晚高峰变慢、白天正常，多半是线路拥塞，不是封锁，换 IP 通常解决不了。
DNS / SNI / TLS / 客户端 / 服务端单节点排查步骤
单节点排查建议从服务端往外查，每一步都确认正常后再进入下一步：
1. 服务端进程：执行 systemctl status xray 确认服务在运行，用 ss -tlnp | grep 443 确认端口在监听，再用 journalctl -u xray -n 50 查看最近的报错，例如证书读取失败、端口占用等。 2. 防火墙：检查 ufw status 或 iptables 规则，同时核对云厂商安全组是否放行了该端口的 TCP（必要时还有 UDP）。 3. DNS：分别执行 dig +short node.example.com 和 dig +short node.example.com @1.1.1.1，确认两边解析结果一致，并且指向当前入口 IP。结果不一致时，排查解析污染或记录未更新。 4. TLS 与 SNI：执行 openssl s_client -connect 入口IP:443 -servername node.example.com，检查证书链和有效期。海外握手成功、国内失败，指向 SNI 或 IP 被干扰。 5. 客户端：核对 UUID、端口、传输方式、SNI 与服务端配置是否一致，更新订阅后查看客户端日志。
五步都正常但国内仍不通时，才把问题判定为封锁，并转入入口、中转、落地的分层定位。
修复后的覆盖验证：多运营商、多客户端交叉确认
换 IP、改 SNI 或调整端口后，只在自己电脑上连通一次，不能说明问题已经解决。验证至少要覆盖三个维度：电信、联通、移动三网；家庭宽带与移动数据；常用客户端，例如 Clash 系、sing-box 与 v2rayN。每个维度先用 nc -vz 入口IP 443 确认 TCP 可达，再用 curl -v --resolve 你的SNI:443:入口IP https://你的SNI/ 观察 TLS 握手是否完成，最后在客户端里看真实请求是否返回。
判断逻辑可以这样走：TCP 通、TLS 握手超时，多半是 SNI 或特征层面被干扰，下一步检查证书域名与伪装配置；TCP 和 TLS 都通、客户端仍报超时，多半是协议参数或订阅下发不一致，下一步核对面板与节点端的 UUID、传输方式和端口。验证结果建议按“运营商 × 客户端 × 层级”记成表格，并持续观察 24 到 72 小时，因为很多干扰会在晚高峰或连接量上来之后才出现。
失败边界：哪些情况换 IP、改配置解决不了
自助排查有明确的边界。第一种情况：新 IP 上线后几小时到几天内又失效，而且换了几次都是同样的节奏。这说明问题不在某个 IP，而在入口特征、流量模式或暴露方式，继续轮换只会持续增加成本。第二种情况：只有某一家运营商不通，其他网络正常。这更接近路由劣化或 QoS 限速，换协议往往没有效果，应该考虑调整线路或增加该运营商方向的入口。
第三种情况是源站已经暴露。如果落地机 IP 曾直接写在订阅里，或者面板域名、节点域名解析到了同一台机器，那么只换入口，后端仍然可能被定位。最后还要承认一个现实：敏感时期的整体网络策略收紧不是运营者能修复的，任何配置都只能降低受影响的程度，不能做出不受影响的承诺。遇到这几类情况，应该停止反复试错，回到架构层面重新规划。
长期架构与服务适用边界：入口、转发、后端解耦
反复失效的长期解法，是把入口、转发和后端拆开。入口层准备多个、分属不同服务商和网段的 IP 或域名，订阅只下发入口地址；转发层负责把流量送到落地，可以随时替换而不改动用户配置；后端落地机不对公网直接暴露，只接受来自转发层的连接。再配合健康检查与切换规则，单个入口失效时，影响范围可以控制在一层之内，而不是整站中断。在 XBoard/V2Board 面板里，节点要按层级命名和分组，方便批量更新和定位。
如果你只遇到单个节点配置错误，前文的步骤通常足以自行解决。当多个入口或中转频繁失效、换 IP 后短期内又反复出现，或者需要明确区分入口、中转与落地故障并设计切换方案时，可以参考 Manguo Labs 的机场高可用入口解决方案（https://manguolabs.com/node-firewall/）。它覆盖多线路规划、批量部署、降低源站暴露风险，以及客户端检查与故障排查，具体效果取决于线路条件和现有架构。
什么时候这已经不是单点配置问题
如果按上述步骤确认问题已不局限于单个节点，例如多个入口轮流失效、换 IP 后很快再出问题，或无法判断故障落在入口、中转还是落地，说明需要从架构层面处理。Manguo Labs 为机场运营者提供入口、中转与落地链路的高可用规划和故障排查方案，可作为参考。
Manguo Labs 能提供什么
Manguo Labs 为机场运营者提供入口、中转与落地链路的高可用规划和故障排查方案。
本文排查流程对应 Manguo Labs 机场高可用入口解决方案的适用范围：多个入口或中转频繁失效、换 IP 后短期内反复出现，以及需要区分入口、中转与落地故障并设计切换方案。单个节点配置错误可按文中步骤自行处理。
适合这些情况
- 多个入口或中转频繁失效的机场运营者
- 换 IP 后短期内反复出现封锁的场景
- 需要区分入口、中转与落地故障并设计切换方案的团队
常见问题
怎么快速判断节点是被墙还是服务端挂了？
从境外机器执行 nc -zv IP 端口 或 curl -v 到服务端口：境外能通、国内多地多运营商 TCP 超时，倾向 IP 或端口封锁；境外也不通，先查 systemctl status、监听端口（ss -lntp）和防火墙规则，属于服务端问题。
TCP 能连上但客户端一直超时，可能是什么原因？
常见是 TLS 层问题：证书过期、SNI 与证书域名不一致、REALITY/目标站配置错误，或握手阶段被干扰。用 openssl s_client -connect IP:端口 -servername 域名 观察是否出现 reset 或无证书返回，再对照服务端日志确认。
只有部分用户或部分运营商连不上，算被墙吗？
不一定。单一运营商或地区异常，可能是该线路路由劣化、QoS 限速或区域性干扰。应收集用户所在运营商、时间段与客户端日志，并从同运营商探测点 mtr 对比，再决定是否调整入口线路，而不是直接判定整机被封。
换 IP 后几天又失效，说明什么？
通常说明问题不在单个 IP，而在暴露方式：入口与源站耦合、流量特征明显、订阅泄露导致入口地址被批量收集等。此时继续换 IP 只是延缓，需要把入口、转发与后端解耦，并准备切换方案。
有中转的链路怎么判断是哪一段出问题？
分段测试：用户到入口、入口到中转、中转到落地各自做 TCP 与延迟检查。用户到入口不通 → 入口问题；入口到落地正常但用户整体不通 → 查入口转发规则；落地访问目标站异常 → 落地出口问题。
总结与下一步
防墙排查的核心是分层：先用境内外对比区分封锁、配置和网络波动，再逐层检查 DNS、SNI、TLS、客户端与服务端，最后按入口、中转、落地定位故障段。单节点问题可通过修正配置或临时换 IP 缓解；若多个入口反复失效、换 IP 后很快再出问题，应转向入口、转发与后端解耦的高可用架构。
需要进一步评估时，可先查看机场高可用入口解决方案，并参考更多技术文章。
继续阅读
了解 机场高可用入口解决方案 →