部署完成后，在美国DDoS高防服务器上执行 ss，可以确认目标端口是否处于监听状态、监听地址是否正确，以及该端口由哪个进程占用。需要注意，ss 只反映当前服务器内核看到的本地套接字，不能单独证明高防入口已经将流量转发到源站；因此应将本机监听结果与授权的外部连通性测试结合判断。

开始前应明确网站使用的协议和端口，例如 HTTPS 通常使用 TCP 443，HTTP 通常使用 TCP 80。如果高防转发到源站时使用了其他端口，应以实际配置的源站端口为准，不要仅凭公网访问端口推断本机监听端口。

准备条件

执行检查前确认以下条件：

• 已通过 SSH、云控制台或带外终端登录服务器。
• 当前账号可以使用 sudo，因为不带足够权限时，ss 可能无法显示其他用户的进程信息。
• 已知网站的监听端口、TCP 或 UDP 协议、预期绑定地址，以及对应的服务名称。
• 已了解高防入口、域名和源站之间的关系。若域名指向高防入口，域名解析出的地址不一定是服务器本机地址。
• 若后续需要修改配置，先保存当前配置和服务状态，不要直接停止未知进程或清空防火墙规则。

先确认系统中存在 ss：

command -v ss
ss -V
sudo -v

ss 通常由 iproute2 提供，适用于常见的 Linux 发行版。如果系统没有该命令，应根据当前发行版的标准软件源补齐对应工具，不要从不明来源下载替代程序。

第一步：保存监听基线

先保存一份只读检查结果，便于修改服务后对比：

sudo ss -H -lntup > "/tmp/ss-listen-$(date +%F-%H%M%S).txt"

其中：

• -l：只显示监听或等待接收的套接字。
• -n：直接显示数字地址和端口，避免 DNS 或服务名解析干扰。
• -t：显示 TCP。
• -u：显示 UDP。
• -p：显示占用套接字的进程。
• -H：隐藏表头，适合保存或进一步处理。

查看全部监听端口：

sudo ss -lntup

典型 TCP 监听结果可能类似：

LISTEN 0 511 0.0.0.0:443 0.0.0.0:* users:(("nginx",pid=1234,fd=6))
LISTEN 0 128 127.0.0.1:8080 0.0.0.0:* users:(("app",pid=2456,fd=12))

这里可以初步确认：

• 443 由 nginx 进程监听；
• 8080 由应用进程监听；
• users:(...) 中包含进程名、PID 和文件描述符；
• LISTEN 只表示本机已经建立监听，不代表公网一定能访问。

第二步：按目标端口精确查询

如果网站使用 TCP 443，可以将检查范围缩小到指定端口：

PORT=443
sudo ss -lntp "( sport = :${PORT} )"

检查 TCP 80：

PORT=80
sudo ss -lntp "( sport = :${PORT} )"

如果服务使用 UDP，则执行：

PORT=443
sudo ss -lnup "( sport = :${PORT} )"

同时检查 IPv4 和 IPv6，有助于发现服务只绑定某一类地址的情况：

PORT=443

sudo ss -4 -lntp "( sport = :${PORT} )"
sudo ss -6 -lntp "( sport = :${PORT} )"

若希望同时查看目标端口的 TCP 和 UDP 结果，可使用：

PORT=443
sudo ss -lntup "( sport = :${PORT} )"

查询时重点关注 Local Address:Port：

不要把 Recv-Q 或 Send-Q 当作带宽、并发数或防护能力指标。它们主要反映套接字队列状态，不能据此推导美国DDoS高防服务器的线路容量或防护性能。

第三步：核对监听端口对应的服务进程

从 ss 输出中取得 PID 后，继续检查进程的实际身份。以下示例中的 1234 应替换为实际 PID：

PID=1234

sudo ps -p "$PID" -o pid,ppid,user,comm,args
sudo readlink -f "/proc/$PID/exe"

重点核对：

• PID 是否仍然存在；
• 进程名称和启动参数是否属于预期服务；
• 运行用户是否符合最小权限要求；
• 进程的父进程是否是预期的服务管理器或主进程；
• 同一个端口是否同时出现多个不相关进程。

如果服务器使用 systemd，可以进一步查看服务状态：

SERVICE=nginx

sudo systemctl show "$SERVICE" -p MainPID -p ActiveState -p SubState
sudo systemctl status "$SERVICE" --no-pager
sudo systemctl cat "$SERVICE"

MainPID 不一定与 ss 显示的 PID 完全相同。例如，Nginx、PHP-FPM 或部分多进程应用可能由主进程管理多个工作进程。此时应确认服务处于 active 状态，并确认监听端口确实由该服务的工作进程创建。

如果 ss 只显示 systemd，也可能是 systemd socket activation。此类服务由 systemd 先占用端口，收到连接后再启动应用，不能简单据此判断应用异常。应结合对应 socket 和 service 单元检查：

sudo systemctl list-sockets --all
sudo systemctl status .socket --no-pager
sudo systemctl status .service --no-pager

如果服务运行在容器中，还要注意网络命名空间。宿主机上的 ss 可能看到的是发布端口、代理进程或容器映射，而不是容器内应用的真实进程。此时应在正确的容器或网络命名空间中执行检查，并同时核对宿主机端口映射。

第四步：核对应用或反向代理配置

端口监听正确，不代表配置中的上游关系正确。若网站前端使用 Nginx，可以先验证配置语法，再查看实际生效的 listen 项：

sudo nginx -t
sudo nginx -T 2>/dev/null | grep -E '^[[:space:]]*listen[[:space:]]'

重点确认：

• listen 端口是否与高防转发到源站的端口一致；
• 是否错误地绑定到了 127.0.0.1；
• HTTPS 端口是否加载了正确的 TLS 配置；
• 反向代理的上游端口是否与应用通过 ss 显示的端口一致。

如果应用不是 Nginx，不要套用 Nginx 配置命令。可以从服务单元的 ExecStart、环境变量和应用自身配置中确认监听参数：

SERVICE=app-service

sudo systemctl show "$SERVICE" -p ExecStart -p Environment
sudo systemctl cat "$SERVICE"

配置输出可能包含路径、令牌或其他敏感信息，不要直接发布到公开工单或论坛。

第五步：从外部验证高防入口

ss 验证的是服务器本地状态。要判断高防入口是否真正能够连接源站，还需要从授权的外部节点测试网站域名或高防提供的访问地址。

对于 HTTPS：

DOMAIN=www.example.com

curl -I --connect-timeout 5 --max-time 10 "https://${DOMAIN}/"

对于普通 TCP 端口，可以使用：

DOMAIN=www.example.com
PORT=443

nc -vz -w 5 "$DOMAIN" "$PORT"

外部测试应优先使用实际业务域名，而不是直接访问源站 IP。原因包括：

• 域名可能解析到高防入口；
• HTTPS 需要正确的 SNI 和证书；
• 直接暴露源站地址可能绕过预期的防护路径；
• 高防转发的源站端口可能与公网访问端口不同。

curl 返回 200、3xx 或部分 4xx，都可能说明 TCP 和 TLS 已经建立，至少证明请求到达了某个 HTTP 服务；但这不代表业务页面完全正常。若 nc 报告连接成功，只能说明 TCP 连接建立，仍应结合应用日志和 HTTP 响应判断业务状态。

UDP 没有像 TCP 那样的连接握手，ss 显示 UDP 套接字只能证明本地已经绑定端口。UDP 服务应使用该协议对应的客户端或业务探针进行验证，不能仅依赖通用的 TCP 连接测试。

结果判断

将本机 ss 结果和外部测试结果放在一起判断：

常见失败处理

目标端口没有监听

先读取服务状态和最近日志，不要立即重启：

SERVICE=app-service

sudo systemctl status "$SERVICE" --no-pager
sudo journalctl -u "$SERVICE" -n 100 --no-pager

常见原因包括：

• 服务启动失败或启动后退出；
• 配置文件中的端口与预期不同；
• 端口被其他进程占用；
• 应用只监听了回环地址；
• 服务运行在容器或其他网络命名空间；
• 实际使用的是 Unix Socket，而不是 TCP 端口。

如果日志显示端口已被占用，先用 ss 查明占用进程，不要直接执行 kill -9。只有在确认进程归属、影响范围和维护窗口后，才考虑停止或调整对应服务。

监听进程不符合预期

例如预期由 Nginx 监听 443，但结果显示为其他应用，可能存在旧进程残留、服务启动顺序错误或端口冲突。应先确认该进程的父进程和启动来源：

PID=1234

sudo ps -p "$PID" -o pid,ppid,user,comm,args
sudo readlink -f "/proc/$PID/exe"

不要通过强制终止未知进程来“释放端口”。错误停止系统服务、代理服务或安全组件，可能导致网站中断或失去远程登录能力。

本机监听正常，但外部无法访问

此时问题通常已经超出 ss 的范围，应按以下顺序核对：

1. 高防入口配置的源站地址和源站端口是否正确。
2. 源站防火墙、安全组或访问控制是否允许预期的高防回源地址。
3. 域名是否仍指向正确的高防入口。
4. 测试时使用的协议是否正确，例如把 HTTPS 端口当作普通 HTTP 访问。
5. 是否存在 IPv4、IPv6 或网络命名空间差异。

不要为了验证连接而临时关闭全部防火墙、放开所有端口或清空现有规则。这类操作会扩大暴露面，也会破坏后续故障定位依据。

修改绑定地址或端口后的回滚

如果确实需要修改应用配置，先备份原文件。以下命令中的路径应替换为实际配置文件：

CONF=/path/to/service.conf
BACKUP="${CONF}.bak.$(date +%F-%H%M%S)"

sudo cp -a "$CONF" "$BACKUP"
printf '备份文件：%s\n' "$BACKUP"

修改前确认变更影响范围：

• 改端口会影响高防转发、反向代理和监控配置；
• 改绑定地址可能使服务暴露到更多网卡；
• 重启服务可能造成连接中断；
• 仅修改本机应用端口而不调整上游配置，会导致代理返回连接失败。

修改后，优先使用应用提供的配置检查命令。以 Nginx 为例：

sudo nginx -t
sudo systemctl reload nginx

reload 是否可用取决于具体服务。没有可靠热加载机制时，使用 restart 会造成服务中断，应在维护窗口内执行：

SERVICE=app-service
sudo systemctl restart "$SERVICE"

如果新配置导致端口消失或服务无法启动，可恢复刚才的备份：

sudo cp -a "$BACKUP" "$CONF"

恢复后再次执行配置检查，并按服务支持的方式重新加载或重启。若同时调整过高防转发、防火墙或安全组，只回退本次变更的对应规则，不要使用清空全部规则的方式恢复。

上线前验收清单

• [ ] sudo ss -lntup 中存在预期的 TCP 或 UDP 监听端口。
• [ ] Local Address:Port 与源站网络架构一致，没有误绑定到错误地址。
• [ ] users:(...) 显示的进程属于预期服务，PID 和启动参数可核对。
• [ ] systemd 服务或其他进程管理器显示服务处于正常运行状态。
• [ ] 应用或反向代理配置检查通过，端口和上游关系一致。
• [ ] 从授权的外部节点通过实际域名完成 TCP、TLS 或业务协议验证。
• [ ] 本次检查结果和配置备份已留存。
• [ ] 没有通过关闭全部防火墙、强制终止未知进程或开放无关端口来完成测试。