浏览器提示连接超时、连接被拒绝，或页面返回 502，看起来都是“网站没起来”，但故障位置并不相同。香港服务器上的网站无法访问时，先记录访问时间、域名、协议和错误信息：超时更偏向网络路径或服务无响应；拒绝连接常见于目标端口未监听或被主动拒绝；502 则说明请求已到达某个网关，需要继续确认后端应用。

排查顺序建议是：先对比外部与本机访问，再查监听端口和服务状态，随后根据日志检查配置、权限及依赖，最后修复并复测。 不要一开始就重启整台服务器、关闭防火墙或放宽目录权限，这些操作既可能扩大影响，也容易破坏现场线索。

一、确认失败发生在哪一层

以下命令适用于使用 systemd 管理服务的 Linux，主要以 Debian、Ubuntu 上的 Nginx 为例。需要具备 SSH 登录和相应的 sudo 权限；example.com、webapp.service、8080 和示例路径都必须替换为实际值。若服务由容器或其他进程管理器托管，应在对应管理层检查，不能直接套用应用服务名。

先在服务器之外的终端请求网站：

curl -v --connect-timeout 5 --max-time 10 \
  -o /dev/null https://example.com/

这是一次真实的 GET 请求，宜选择首页或已知无副作用的健康检查地址。观察连接目标 IP、TLS 握手和 HTTP 状态；分享输出前应隐藏 Cookie、令牌及其他敏感信息。

随后登录服务器，以相同域名测试本机入口：

curl -v --connect-timeout 5 --max-time 10 \
  --resolve example.com:443:127.0.0.1 \
  -o /dev/null https://example.com/

该命令保留域名对应的 Host 和 TLS SNI，同时把连接定向到回环地址，适合 Nginx 监听所有本机地址或回环地址的情况。若只绑定指定网卡地址，应替换 127.0.0.1。HTTP 网站则相应改为 http 和实际端口。

本机访问成功，不代表公网访问一定成功；获得 HTTP 响应，也不代表业务已经正常。 这两点可以避免把网络问题和应用问题混为一谈。

二、查端口和服务状态，不急着重启

确认谁在监听目标端口

在服务器上执行以下只读检查：

sudo ss -lntp

关注实际使用的入口端口和应用端口，检查监听地址、端口及进程信息。

• 没有目标端口：服务可能未启动、提前退出，或实际监听了其他端口。
• 仅监听 127.0.0.1：只能通过本机回环地址连接。对反向代理后的应用通常合理，对直接对外提供访问的入口则需要核对。
• 端口被意外进程占用：可能导致目标服务报 Address already in use。
• 只看到 IPv6 监听：不能直接断言 IPv4 可用或不可用，应分别测试，行为还受系统和套接字设置影响。

发现端口冲突后，先确认占用进程由哪个服务管理、承载什么业务，不要直接杀进程。修复可能是停止误启动的重复实例，也可能是调整监听端口并同步修改代理配置。

确认服务是否真的持续运行

先核对服务单元，再查看状态：

systemctl list-unit-files --type=service
sudo systemctl status nginx.service --no-pager -l
sudo systemctl status webapp.service --no-pager -l

webapp.service 仅代表实际应用单元；不存在时，应从部署配置中确认名称。

状态的含义需要结合端口和日志判断：

• failed：启动或运行过程发生失败，关注退出码和失败时间。
• inactive (dead)：当前没有运行，可能尚未启动，也可能启动后退出。
• activating 持续不结束：可能卡在初始化、启动前命令或依赖等待。
• active (running)：进程存在，但不保证已监听端口或能够处理请求。
• 不断自动重启：往往是“启动—报错—退出”的循环，不能把短暂运行当作恢复。

查看应用实际如何启动：

sudo systemctl cat webapp.service
sudo systemctl show webapp.service \
  -p User -p Group -p WorkingDirectory -p ExecStart \
  -p Result -p ExecMainStatus -p NRestarts

重点核对启动命令、运行用户、工作目录和重启次数。输出可能包含敏感启动参数，不应未经脱敏公开。

三、围绕失败时间找日志，再验证配置

服务状态只说明“失败了”，日志才更可能说明“为什么失败”。尽量在再次启动前保留当前输出，并查看故障时间附近的记录：

sudo journalctl -u nginx.service -b -n 100 --no-pager
sudo journalctl -u webapp.service -b -n 200 --no-pager

这些命令读取本次系统启动以来的最近日志，不修改服务。如果故障发生得更早，应按实际时间使用 --since、--until 缩小范围；历史记录是否存在取决于日志保留设置。

不要只盯着最后一行 Failed to start。应向前寻找首个明确错误，并与最后一次发布、配置修改或证书更新的时间对照。

Nginx 的请求错误还可能写入配置中的 error_log 文件，应用也可能使用独立日志文件。journal 中没有业务异常，不代表没有异常，应确认日志实际写向哪里。

如果怀疑 Nginx 配置错误，可执行：

sudo nginx -t

它检查配置语法并尝试打开配置引用的文件，不执行重载。正常应看到测试成功；失败时先处理明确指出的文件、行号或资源访问问题。检查通过仍不能证明上游应用正常。

如果服务使用自定义二进制或通过 -c 指定配置，应依据服务单元使用相同的程序和配置路径测试，避免检查了另一套配置。

四、根据证据检查权限和依赖

权限：验证真实运行身份能否访问

“SSH 登录用户能读文件”不代表服务用户也能读。假设应用需要读取 /srv/site/current/app.conf，可检查完整路径：

namei -l /srv/site/current/app.conf

该命令显示路径各级目录和目标文件的权限。读取文件不仅要求文件可读，还要求服务用户对每一级父目录具有搜索权限。若系统未安装 namei，可逐级使用 ls -ld 检查。

核对实际运行用户后，再以该身份测试：

sudo -u www-data test -r /srv/site/current/app.conf
echo $?

这里的 www-data 只是示例，必须替换为前面确认的服务用户。紧随测试执行的 echo $? 返回 0 表示可读，非零表示测试未通过。上传、缓存和日志目录还要分别验证写权限。

不要使用 chmod -R 777。确需调整时，先记录目标文件的属主、权限及 ACL，仅修改必要对象，并保留恢复原值的方法。普通权限正常仍被拒绝时，还应查看 AppArmor、SELinux 或 systemd 文件系统隔离设置，不能以关闭安全机制代替定位。

依赖：区分应用未启动与启动后不可用

应用可能等待数据库、缓存、环境变量或本地套接字；运行时和部署产物不匹配也可能导致进程立即退出。判断依据应是该次启动日志，而不是无差别重装依赖。

若 Nginx 代理到本机 HTTP 应用，可绕过代理验证上游：

curl -v --connect-timeout 3 --max-time 10 \
  http://127.0.0.1:8080/health

此处仅适用于上游确实使用 HTTP、监听该地址且存在 /health 的环境；否则替换成实际协议、地址和安全测试路径。不要对 FastCGI 端口直接发送 HTTP 请求。

• 上游连接失败：继续查应用进程、监听地址和初始化错误。
• 上游返回 500：查看应用日志及依赖错误。
• 上游返回预期响应，而入口仍报 502：核对代理目标、协议、套接字权限和对应请求的错误日志。
• 上游返回 404：说明已有 HTTP 服务响应，但可能是路径或虚拟主机不匹配，不能据此判定启动失败。

五、修复后验证完整请求链，并持续观察

修复时一次只处理一个已证实的问题。修改配置前，应把实际涉及的文件备份到不会被配置包含规则加载的位置，保留属主和权限；记录原来的服务状态及改动内容。不要把回滚寄托于“记得改过哪里”。

如果应用确认处于停止状态，原因已修复且允许启动，可执行：

sudo systemctl start webapp.service
sudo systemctl status webapp.service --no-pager -l

启动会实际运行程序，也可能触发初始化任务，应先确认其影响。若修改导致新异常，应恢复原配置或原部署版本，再按既定流程启动；涉及数据库迁移时，不能默认代码回退就能恢复数据。

对于已经运行的 Nginx，配置修复后可先测试再平滑重载：

sudo nginx -t && sudo systemctl reload nginx.service

重载会改变后续请求使用的配置；若服务尚未运行，应在测试通过后使用 start。出现回归时，恢复备份，重新测试，再重载。

最后按以下顺序复测：

1. 进程层：服务持续运行，重启次数没有继续增加。
2. 端口层：目标地址和端口由预期进程监听。
3. 上游层：直接访问应用得到预期状态和内容。
4. 入口层：保留真实域名访问本机入口，确认 TLS 与代理链路。
5. 外部层：从服务器外访问，并验证关键业务页面或只读接口。

复测后继续观察服务日志、访问错误和健康检查，覆盖依赖重连及实际请求处理过程。只有进程、监听端口、请求响应和日志表现相互印证，才能确认香港服务器上的网站已经恢复，而不是仅仅执行了一次成功的启动命令。