VPS知识分享站先说结论：服务器端口不通，要沿数据路径逐层检查：客户端与 DNS → 公网 IP/路由 → 云安全组 → 系统防火墙 → 进程监听 → 容器或反向代理 → 应用协议。不要先把来源改成 0.0.0.0/0、关闭防火墙或重装系统；这些操作既扩大风险，也会破坏定位证据。
先区分四种结果
| 现象 | 常见含义 | 下一步 |
|---|---|---|
| 连接超时 | 请求或响应被丢弃、路由错误、地址错误 | 查 DNS/IP、网络、安全组和防火墙 |
| Connection refused | 目标主动拒绝或没有进程监听 | 查监听、服务状态和拒绝规则 |
| TCP 成功但业务失败 | TLS、Host、认证、反向代理或应用问题 | 用真实协议和日志排查 |
| 只有部分地区失败 | 来源白名单、运营商路径、IPv4/IPv6 或防护策略 | 分来源、分地址族对比 |
nc 显示 TCP 建连成功，只能证明传输层成功，不能证明 HTTPS、数据库或自定义协议工作正常。
第 1 步：确认测试目标没有错
- 域名 A/AAAA 是否指向当前实例、负载均衡或 CDN；
- 测试的是公网 IP 还是只在私网可达的地址；
- 端口、协议 TCP/UDP 和 IPv4/IPv6 是否与服务一致；
- 实例是否运行，公网 IP、网卡、安全组绑定是否刚发生变化；
- 业务是否本来只允许从 VPN、堡垒机或办公网访问。
dig A example.com
dig AAAA example.com
curl -4 https://example.com/
curl -6 https://example.com/
若整台实例多种协议都不可达，先按云服务器 IP 连接不上排查处理。
第 2 步：从正确的客户端做 TCP 测试
# macOS / Linux
nc -vz -w 5 203.0.113.10 443
# Windows PowerShell
Test-NetConnection 203.0.113.10 -Port 443
用主要用户网络、另一运营商和受信任运维网络分别测试，记录时间、来源公网 IP、目标、协议和结果。公司出口可能限制管理端口，服务器也可能只对白名单开放；换网络能帮助定位，但不能证明哪一层一定故障。
UDP 没有和 TCP 相同的握手，简单 nc -u 没响应不能直接证明 UDP 被阻断。应使用对应业务协议、服务端抓包或明确的探测工具验证。
第 3 步：检查云安全组
确认规则关联到正确实例/网卡，并核对：
- 方向是入站还是出站；
- 协议与端口范围正确；
- 来源 CIDR 包含测试客户端当前公网 IP；
- IPv4 与 IPv6 规则分别存在；
- 是否有优先级更高的拒绝规则或网络 ACL；
- 返回流量、负载均衡健康检查和上游依赖是否允许。
管理端口、数据库、面板和监控端口优先限定为管理员地址、堡垒机、私网或企业 VPN。网站 80/443 面向公网时，也只开放实际需要的协议。详见安全组最小权限配置。
第 4 步：检查系统防火墙
# Ubuntu / Debian 常见
sudo ufw status verbose
# RHEL 系常见
sudo firewall-cmd --list-all
# nftables
sudo nft list ruleset
不要通过停止整个防火墙来做常规排查。更安全的方法是查看规则、计数器和日志，添加仅允许测试源 IP 到目标端口的临时规则，验证后删除。若使用 iptables、nftables、UFW 和 firewalld 中多个管理层，还要确认它们是否生成冲突规则。
第 5 步：确认进程真的在监听
sudo ss -lntup
sudo systemctl status nginx
sudo journalctl -u nginx --since "30 minutes ago"
重点看本地地址：
127.0.0.1:8080只接受本机访问，适合作为反向代理上游；0.0.0.0:8080监听所有 IPv4 网卡，不代表防火墙已经允许；[::]:8080是否同时接受 IPv4 取决于系统配置，需分别测试；- 没有监听记录时，应检查服务启动、配置语法、端口冲突和应用日志。
不要为了外部访问直接把数据库改成监听所有网卡。数据库优先通过私网、SSH 跳板、VPN 或受控代理访问，并保留认证与 TLS。
第 6 步：容器端口怎样排查？
docker ps --format 'table {{.Names}}\t{{.Ports}}'
docker inspect CONTAINER_NAME
docker logs --tail 100 CONTAINER_NAME
容器内应用监听、容器端口、宿主机发布端口和防火墙是不同层。Docker 官方端口发布文档提醒，未指定主机地址时，发布端口默认可能对所有主机地址可用。只需本机反向代理访问时，应显式绑定回环地址，例如：
docker run -p 127.0.0.1:8080:80 IMAGE
如果确实需要公网访问，再通过安全组、主机防火墙、认证和 TLS 限制暴露面。Docker Compose、Kubernetes Service/Ingress 还应分别检查映射、选择器、健康状态和网络策略。
第 7 步：TCP 通但网页或 API 不通
使用真实协议检查，不要只测端口：
curl -vk --connect-timeout 5 https://example.com/
openssl s_client -connect example.com:443 -servername example.com </dev/null
常见原因包括：
- Nginx/Apache 的 Host、SNI、虚拟主机或证书配置不匹配；
- 反向代理 upstream 地址、端口、超时或健康检查错误；
- 应用返回 401/403/5xx，而不是网络端口问题；
- CDN/WAF 只允许特定源站端口或阻断测试来源；
- WebSocket、gRPC、回调等协议没有在代理层正确传递；
- 应用线程、连接池、数据库或磁盘耗尽导致超时。
域名和网站层问题可继续参考域名解析后网站打不开排查。
第 8 步：必要时抓包定位边界
在确认有授权且不会采集敏感业务数据的前提下，可在服务器观察目标端口是否收到 SYN：
sudo tcpdump -ni any 'tcp port 443'
- 完全看不到请求：优先查目标地址、路由、安全组、上游 ACL；
- 看到 SYN 但没有 SYN-ACK：查主机防火墙、监听和内核；
- 完成握手后立即断开：查 TLS、认证和应用日志；
- 服务端响应已发出但客户端收不到：查回程路由、NAT 与非对称路径。
抓包可能包含地址和业务内容，应限制过滤条件、保管和留存时间。
修复时怎样避免安全倒退？
- 记录修改前规则、配置和服务状态；
- 只修改一个层级，立即复测；
- 临时规则限定来源 IP、目标端口和有效窗口；
- 配置变更先做语法检查，再 reload；
- 保留控制台或第二条管理连接，避免把自己锁在门外；
- 验证后删除临时全开、调试账号和测试容器；
- 记录根因和回退命令，补监控和自动化检查。
修复后的验收清单
- 授权来源能用真实协议完成业务，非授权来源仍被拒绝；
- IPv4/IPv6、域名、负载均衡和所有后端结果一致；
- 安全组、系统防火墙与文档中的端口清单一致；
- 服务只监听所需网卡和端口，没有意外暴露数据库或面板；
- 应用日志、错误率、延迟与资源恢复正常；
- 重启服务或实例后规则和监听仍然存在；
- 端口扫描、异常登录和服务停止已有告警。
需要换服务器吗？
大多数端口故障来自规则、监听和应用配置，不需要更换 VPS。只有证据显示当前节点存在持续路由故障、产品不支持所需网络能力，或旧系统无法安全维护时才评估迁移。需要测试/替换环境时，可在萤光云 VPS 产品页核对当前节点和网络，并用测试 IP 验收方法验证。
常见问题
安全组放行后为什么仍不通？
继续检查系统防火墙、服务监听、绑定地址、容器映射和应用协议；安全组只是数据路径的一层。
Connection refused 一定是防火墙吗？
不一定。它通常说明目标主动拒绝，常见于没有服务监听，也可能是明确的 reject 规则。
能临时对全网开放排查吗？
不建议。优先只允许当前测试公网 IP，并设置明确的删除时间；数据库和管理面板尤其不能用全网开放验证。
