VPS知识分享站搜索“IP 被墙怎么办”时，最容易犯的错误是只做一次
Ping，就直接判断必须换 IP。Ping 不通只能说明 ICMP
没有得到响应，不能单独证明 IP 被封锁。
正确做法是先排除服务器宕机、安全组、系统防火墙、DNS、端口监听和线路故障，再用多个地区、多个协议的结果判断是否存在明显的地域性不可达。
如果业务正在中断，先不要重装系统或反复修改网络。保存当前配置和检测结果，按照本文的顺序排查，才能避免把普通故障误判为“被墙”。
先用 1
分钟判断问题属于哪一层
| 现象 | 更可能的问题 | 下一步 |
|---|---|---|
| 所有地区都无法访问 | 服务器宕机、安全组、防火墙、服务未监听 | 先检查控制台和本机服务 |
| 域名不能访问，直接访问 IP 正常 | DNS、DNSSEC、解析记录或缓存 | 检查 dig / nslookup |
| Ping 不通，但网站和 SSH 正常 | ICMP 被禁用或限速 | 不需要仅因 Ping 更换 IP |
| 只有 80/443 不通 | Web 服务、安全组、证书或反向代理 | 检查端口与 Web 日志 |
| 境外节点正常，多个境内网络持续失败 | 跨境路由或地域性过滤的可能性较高 | 做多地 TCP 与路由对比 |
| 只有某个运营商失败 | 运营商互联或局部路由故障 | 保存 MTR 并联系服务商 |
| IP 正常，只有某个账号或平台失败 | 平台风控、账号或环境问题 | 不要直接归因于 IP 被墙 |
IP 被墙通常会出现什么现象
用户口中的“IP 被墙”，一般指某个公网 IP
从中国境内多个网络持续无法建立连接，而境外网络仍可正常访问。常见表现包括：
- 境内多个运营商访问同一 IP 超时；
- 境外监测节点访问网站或端口正常；
- 服务器本身运行正常，出站访问也正常；
- 更换同服务器的公网 IP 后连接恢复；
- 域名解析到另一个健康 IP 后访问恢复；
- 问题持续存在，而不是几分钟的临时丢包。
这些现象组合出现时，判断才更有把握。一次失败、单个运营商失败或单一工具失败，都不足以作结论。
排查前先保存证据
建议建立一份故障记录，至少包含：
- 出问题的域名、IP、端口和协议；
- 首次发生时间和时区；
- 服务器地域、服务商和实例 ID；
- 境内、境外各两个以上测试点的结果；
- DNS 解析结果；
curl、端口测试和traceroute/
mtr输出；- 安全组、防火墙和服务监听截图；
- 最近 24 小时是否改过 DNS、证书、网络或系统。
这份记录既能帮助自己判断，也能让服务商更快定位问题。
第一步：确认服务器没有宕机
先在云平台控制台检查实例状态、CPU、内存、磁盘和网络监控。如果 SSH
连接不上，使用服务商提供的 VNC、串口或救援模式登录。
Linux 中可以检查：
uptime
free -h
df -h
ip addr
ip route如果磁盘已满、内存耗尽、默认路由丢失或网卡没有地址，应先解决服务器本身问题。
第二步：确认服务确实在监听
网站打不开不代表 IP 不通。检查应用是否监听在正确端口和公网网卡：
sudo ss -lntup
sudo systemctl status nginx
sudo systemctl status apache2如果服务只监听 127.0.0.1，外部无法直接访问；如果
Nginx、Apache 或应用进程已经停止，换 IP 也不会解决问题。
第三步：检查安全组和系统防火墙
同时检查云平台安全组与服务器内部防火墙。常见问题包括：
- 只允许了旧办公 IP；
- 只开放 IPv6，没有开放 IPv4；
- 端口范围或协议选错；
- 防火墙更新后默认策略变为拒绝；
- Fail2Ban 或安全软件误封了测试来源；
- Web 服务实际使用 8443，但安全组只开了 443。
Linux 中可按实际系统检查：
sudo ufw status verbose
sudo firewall-cmd --list-all
sudo nft list ruleset不要为了测试直接永久关闭所有防火墙。优先添加一条范围明确、可回滚的临时规则。
第四步：把 DNS 问题和 IP
问题分开
分别测试域名与 IP。Linux 或 macOS 可以执行：
dig +short example.com A
dig +short example.com AAAA
curl -I --connect-timeout 10 https://example.com
curl -I --connect-timeout 10 --resolve example.com:443:203.0.113.10 https://example.comWindows 可用：
nslookup example.com
Test-NetConnection example.com -Port 443
Test-NetConnection 203.0.113.10 -Port 443--resolve 可以在不修改公共 DNS 的情况下，让
curl 使用指定 IP，同时保留正确的域名和 TLS SNI。若指定 IP
正常而公共解析失败，应优先修复 DNS；若域名和 IP
都失败，再继续检查网络。
Google Public DNS 的故障排查文档也建议比较多个公共解析器，并区分 DNS
解析、权威服务器和网络连接问题。
第五步：不要只测
Ping，要测业务端口
Ping 使用 ICMP，很多机房、系统和安全设备会限制 ICMP，但不会影响 TCP
业务。
测试 SSH 和 HTTPS：
nc -vz -w 5 203.0.113.10 22
nc -vz -w 5 203.0.113.10 443
curl -v --connect-timeout 10 https://example.com/Windows：
Test-NetConnection 203.0.113.10 -Port 22
Test-NetConnection 203.0.113.10 -Port 443重点记录是 DNS 失败、TCP 超时、TCP 被拒绝、TLS 握手失败，还是应用返回
4xx/5xx。这五类错误的处理路径完全不同。
第六步：使用多地区、多个运营商测试
至少选择：
- 中国境内电信、联通、移动中的两个或三个网络；
- 服务器所在地区附近的一个境外节点；
- 另一个不同地区的境外节点；
- HTTP/HTTPS 和实际业务端口；
- IPv4 与 IPv6（如果业务同时启用）。
如果境外多个节点正常，而境内多个运营商的 TCP
连接在较长时间内都失败，地域性不可达的可能性才会明显提高。
第七步：比较去程和回程路由
客户端到服务器是去程，服务器到客户端是回程，两条路径可能不同。只看一侧
traceroute 容易误判。
客户端侧：
traceroute -n 203.0.113.10
mtr -rwzc 50 203.0.113.10服务器侧应对一个有授权的测试地址做反向测试：
mtr -rwzc 50 <测试客户端IP>中间某一跳不回复并不等于从那里开始被阻断。路由器可能降低 ICMP
优先级，但仍正常转发后续流量。应关注最后是否能到达、从哪一段开始所有后续节点都持续丢失，以及多个测试点是否出现相同模式。
怎么综合判断是否真的“被墙”
可以用下面的证据矩阵：
| 证据 | 支持“地域性不可达” | 不足以单独证明 |
|---|---|---|
| 境外 TCP 端口正常 | 是 | — |
| 境内多个运营商 TCP 持续超时 | 是 | 单一运营商超时 |
| 服务器控制台和服务监听正常 | 是 | 只看实例“运行中” |
| 换 IP 后相同配置立即恢复 | 较强证据 | 更换系统、配置后恢复 |
| Ping 不通 | — | 是 |
| Traceroute 中间出现星号 | — | 是 |
| 某个第三方检测站标红 | — | 是 |
| 域名解析失败 | 更像 DNS 问题 | 是 |
确认 IP 不可达后怎么办
方案一：联系服务商更换公网 IP
这是非 Web
服务和需要直接连接服务器时最常见的恢复方式。提交工单时提供：
- 原 IP 和目标端口；
- 境内外对比结果；
- 故障开始时间；
- 安全组和监听状态；
- MTR 或 Traceroute；
- 是否接受付费换 IP。
更换前确认新 IP 的费用、次数限制、地址段和退款规则。更换后要同步修改
DNS、白名单、证书验证、监控和第三方回调配置。
方案二：Web 业务使用 CDN
或反向代理
如果业务是 HTTP/HTTPS 网站，可以让支持代理的 CDN
节点接收访问，再回源到服务器。Cloudflare
的官方说明指出，启用代理后，访问者获得的是 Cloudflare
网络地址，而不是源站实际 IP。
CDN 不是所有服务的通用解决方案：
- 普通 CDN 通常不能代理 SSH、远程桌面或任意 TCP 端口；
- 源站仍要允许 CDN 节点正常回源；
- 应限制源站只接受可信代理来源，避免真实 IP 继续暴露；
- 应正确恢复访客真实 IP，避免日志、限速和风控失效；
- 证书、缓存和 WebSocket 需要单独检查。
方案三：切换备用节点
关键业务应提前准备另一个地域或服务商的备用节点，并完成：
- 数据同步；
- 健康检查；
- DNS 低 TTL；
- 自动或手工切换流程；
- 证书和密钥同步；
- 回滚步骤；
- 切换演练。
没有提前准备的“多节点”只是多个服务器，不是可用的容灾方案。
方案四：修复真正的根因
如果调查发现是服务器被入侵、对外攻击、开放代理、异常爬虫或配置错误，应先处理根因，再申请换
IP。否则新 IP 可能很快出现同样问题。
建议检查：
sudo journalctl --since "24 hours ago"
sudo last
sudo ss -antup
sudo find /var/log -type f -mtime -1同时更新系统与应用、轮换泄露凭据、关闭无用端口、限制管理入口，并检查云平台流量监控。
如何降低再次发生的概率
- 只开放业务必需端口；
- SSH 使用密钥认证，并限制管理来源；
- 及时更新系统、面板、WordPress 和插件；
- 为登录、API 和爬虫设置合理限速；
- 监控出站流量、连接数、CPU、磁盘和异常进程；
- Web 业务使用 WAF、CDN 和源站访问控制；
- 定期做境内外多点可用性检测；
- 准备备份、快照和恢复演练；
- 对关键业务准备第二节点和切换文档；
- 遵守用户所在地和服务器所在地适用的法律及服务条款。
如果你正在评估服务器 IP 类型，可先阅读 原生 IP 和广播 IP
的区别与检测方法；如果问题源于配置选择，可以参考 VPS 购买配置指南。
常见问题
IP 被墙后只能换 IP 吗
不一定。先判断业务类型和根因。Web 业务可能通过正确配置的 CDN
恢复；DNS、安全组、服务停止等问题应直接修复；需要直接连接该公网 IP
的服务，确认地域性不可达后通常需要更换 IP 或切换节点。
IP 被墙会自己恢复吗
无法保证。短时路由波动可能自行恢复，但持续的地域性不可达不应依赖等待。关键业务应先切换，再继续调查。
Ping 不通就是 IP 被墙吗
不是。ICMP
可能被服务器、防火墙或中间网络限速和丢弃。必须测试实际业务端口。
网站能打开，SSH 不能连接，是
IP 被墙吗
通常不是整体 IP 不可达，更可能是 22 端口、安全组、SSH 服务、Fail2Ban
或管理来源限制。分别测试端口并查看服务日志。
域名被污染和 IP
被墙是一回事吗
不是。DNS 问题影响域名解析，IP 可达性问题影响对具体地址的连接。用指定
IP 的
curl --resolve、不同解析器和直接端口测试可以帮助区分。
换 IP 后要修改哪些地方
至少检查 DNS A/AAAA 记录、CDN 源站、第三方白名单、支付或 API
回调、监控、备份任务、邮件 SPF、反向 DNS、证书验证和团队文档。
结论
处理“IP
被墙”的正确顺序是：先确认服务器和服务正常，再排除安全组、防火墙与
DNS，然后使用多地区、多运营商和真实业务端口对比，最后才决定换 IP、上 CDN
或切换备用节点。把每次检测结果保存下来，比只看一次 Ping
更快找到根因，也能避免在没有证据时反复更换服务器。
