首次把网站部署到香港服务器时，页面“可访问”不能只看 Nginx 进程是否运行。至少要确认访问请求能够沿着“域名或 IP → 端口 → Nginx 站点配置 → 网站文件或应用进程 → HTTP 响应”完整走通。最小验证闭环是：先执行 nginx -t 检查配置，再加载配置，随后用本机请求确认 Nginx 能返回内容，最后从服务器外部通过域名或公网 IP 验证。

执行变更前，准备好 SSH 登录权限、具有 sudo 权限的账号、服务器公网 IP、实际使用的域名、网站目录或应用监听地址，并确认当前网站是否已经有可用配置。对已有站点，先备份 Nginx 配置和将被替换的文件；对新站点，尽量只新增一个独立配置文件，不要一次性修改多个无关服务。

先确认访问范围和当前状态

以下步骤以 Linux、Nginx、systemd 为基础环境，示例以静态网站为主。将示例中的 example.com、203.0.113.10 和网站目录替换为实际值。203.0.113.10 仅作为文档示例地址，不代表任何真实服务器地址。

先确认 Nginx 是否已经安装，以及当前是否由 systemd 管理：

command -v nginx
nginx -v
sudo systemctl is-active nginx

几个结果的含义如下：

• 能输出 Nginx 路径和版本，但服务处于 inactive，说明软件已安装，尚未启动或当前未运行。
• command -v nginx 没有输出，说明当前命令路径中没有 Nginx，需要先按照所用发行版的官方软件源完成安装。
• systemctl 找不到 nginx.service，说明服务名称或启动方式可能不同，不要直接猜测服务名，应先检查已安装的服务单元。
• 服务处于 active，也不能证明当前域名已经指向正确站点，还需要继续检查监听端口、server_name 和网站根目录。

确认域名解析是否已经指向这台香港服务器。可以在服务器或外部测试设备上执行：

dig +short example.com A
dig +short example.com AAAA

如果系统没有安装 dig，可以使用：

getent ahosts example.com

A 记录应当与服务器实际公网 IPv4 地址一致。如果存在 AAAA 记录，还要确认服务器已经配置 IPv6 监听并具备可用的 IPv6 网络；如果当前只准备了 IPv4，不能让 AAAA 记录把部分访问请求导向未配置的地址。

如果 DNS 还没有切换，也可以先用公网 IP 验证 Nginx，再用 curl --resolve 在不修改 DNS 的情况下测试指定域名。这样既能保留正确的 Host 请求头，也能避免因为默认站点导致误判。

备份配置并缩小变更范围

修改前先保存当前 Nginx 配置。下面的命令会将整个 /etc/nginx 目录打包到 /root，需要确认服务器磁盘空间足够，并且当前账号具备 root 权限：

sudo tar -czf /root/nginx-backup-$(date +%Y%m%d%H%M%S).tar.gz /etc/nginx

如果只新增一个站点配置，也建议单独保留原文件。文件存在时再执行对应命令：

sudo cp -a /etc/nginx/sites-available/example.com /root/example.com.nginx.before

不同发行版的站点配置位置可能不同：

• Debian 或 Ubuntu 常见位置是 /etc/nginx/sites-available/，再通过 /etc/nginx/sites-enabled/ 中的软链接启用。
• RHEL 系列发行版常见位置是 /etc/nginx/conf.d/，配置文件通常以 .conf 结尾。
• 如果不确定主配置加载了哪些目录，可以查看完整配置：

sudo nginx -T

nginx -T 会把主配置和被加载的子配置输出到终端。重点检查是否已经存在相同的 listen 和 server_name。如果已有站点配置处理 example.com，应当修改原配置，而不是再添加一个相同域名的服务块，否则请求可能被已有默认站点接收。

写入静态网站的最小配置

先确认网站文件存在。新建空目录时可以执行：

sudo install -d -m 0755 /var/www/example.com
sudoedit /var/www/example.com/index.html

在编辑器中写入一段容易识别的测试页面：

    
    


    
example.com is working
    
nginx-static-check

如果目录中已经有正式网站，不要用测试页面覆盖原首页。应当保留现有文件，通过页面中的固定文字、版本标识或实际业务内容确认返回结果。

检查目录和文件的读取路径：

namei -l /var/www/example.com/index.html
stat -c '%A %U:%G %n' /var/www/example.com/index.html

Nginx 工作进程需要能够进入网站目录并读取文件。namei 可以逐级显示路径权限，适合排查目录没有执行权限、文件归属不合适等问题。不要在不了解现有权限模型的情况下对整个网站目录执行递归 chmod 或 chown；如果只是新建的静态目录，再按照现有系统的 Nginx 用户和权限规范调整目标文件。

编辑站点配置：

sudoedit /etc/nginx/sites-available/example.com

静态网站的最小配置可以写成：

server {
    listen 80;
    server_name example.com;

    root /var/www/example.com;
    index index.html;

    location / {
        try_files $uri $uri/ =404;
    }
}

如果 www.example.com 也已经解析到同一台服务器，并且需要由这个站点处理，可以改为：

server_name example.com www.example.com;

不要把尚未解析或尚未准备好的域名直接写入生产配置，以免后续通过该域名测试时误判。

在 Debian 或 Ubuntu 的常见布局中，启用新配置前先确认目标软链接不存在：

sudo ln -s /etc/nginx/sites-available/example.com /etc/nginx/sites-enabled/example.com

如果使用的是 /etc/nginx/conf.d/，则应将同一份配置保存为类似下面的文件名：

/etc/nginx/conf.d/example.com.conf

不要同时在 sites-enabled 和 conf.d 中放入相同的服务块。

先检查配置，再首次启动或重新加载

配置文件写好后，第一步始终是语法检查：

sudo nginx -t

看到 syntax is ok 和 test is successful，只说明 Nginx 能够读取配置、解析语法，并且相关文件引用没有立即报错。它不能证明域名解析正确、端口能够从外部访问、网站内容存在，也不能证明反向代理后端进程健康。

如果检查失败，不要继续 reload。根据错误信息修正：

• duplicate listen 或类似冲突，通常表示监听地址、端口或服务块重复。
• unknown directive，通常表示指令拼写错误、模块不兼容或配置放置位置不合适。
• open() ... failed，通常表示证书、网站目录、日志路径或被 include 的配置文件不存在。
• permission denied，通常涉及配置文件、日志目录或网站文件的读取权限。

确认检查成功后，根据当前服务状态选择启动或重新加载：

if sudo systemctl is-active --quiet nginx; then
    sudo systemctl reload nginx
else
    sudo systemctl start nginx
fi

首次启动或 reload 后立即查看状态：

sudo systemctl is-active nginx
sudo systemctl status nginx --no-pager
sudo journalctl -u nginx -n 50 --no-pager

如果站点已经通过本机验证并且需要服务器重启后自动启动，再执行：

sudo systemctl enable nginx

enable 只改变开机启动行为，不是验证页面可访问的必要步骤。对于生产服务器，应在确认配置和站点响应正常后再做这项持久化变更。

按顺序验证页面是否真正可访问

第一步：确认 Nginx 正在监听目标端口

先看本机监听情况：

sudo ss -lntp | grep -E ':(80|443)[[:space:]]'

如果只部署 HTTP，重点查看 80 端口；如果已有 HTTPS 配置，再检查 443 端口。没有任何输出时，通常表示 Nginx 没有监听该端口、配置使用了其他端口，或服务没有成功启动。

可以从当前生效配置中确认监听和域名：

sudo nginx -T | grep -nE '^[[:space:]]*listen|^[[:space:]]*server_name'

第二步：从服务器本机请求页面

不要一开始就直接用公网域名判断。先在服务器上访问本机 Nginx：

curl -i -H 'Host: example.com' http://127.0.0.1/

这里显式设置 Host 很重要。直接执行 curl http://127.0.0.1/ 时，请求可能落到默认服务块，返回的页面不一定属于 example.com。

成功时，响应中通常应看到类似：

HTTP/1.1 200 OK
Content-Type: text/html

并且响应正文包含实际网站内容或预先设置的识别文字。如果返回的是默认 Nginx 页面，通常不是 Nginx 没启动，而是 server_name 没有匹配到当前请求，或者站点配置没有被加载。

如果页面配置为 HTTP 跳转，可以使用：

curl -i -L -H 'Host: example.com' http://127.0.0.1/

-L 会跟随跳转，但最终仍要确认跳转目标是否正确。不要仅凭 curl -I 判断所有网站，因为有些应用对 HEAD 请求的处理与 GET 不同；首次验证建议使用普通 GET 请求。

第三步：从外部验证公网 IP

本机返回正常后，再使用服务器外部的设备或网络测试公网入口。若 DNS 已经正确解析，可以直接执行：

curl -i http://example.com/

如果 DNS 尚未切换，使用公网 IP 和 --resolve：

curl -i --resolve example.com:80:203.0.113.10 http://example.com/

该命令会把 example.com 的本次请求定向到指定 IP，同时保留正确的域名请求头。测试应尽量从服务器外部执行；在服务器本机访问自己的公网 IP，可能受到本机路由或安全策略影响，不能完全代替外部验证。

如果网站使用 HTTPS，还应验证 443 端口：

curl -i --resolve example.com:443:203.0.113.10 https://example.com/

正式验证时不要使用 -k 忽略证书错误，否则可能把域名不匹配、证书过期或证书链异常掩盖掉。HTTP 跳转到 HTTPS 时，应分别检查 HTTP 的跳转位置和 HTTPS 的最终响应。

不同响应结果代表什么

从外部访问失败时检查端口和防火墙

如果本机请求已经返回正确页面，但外部请求超时或被拒绝，问题通常已经从网站文件层转移到了监听地址、系统防火墙、服务器控制台入站规则或 DNS。

先确认 Nginx 是否监听了公网可到达的地址：

sudo ss -lntp | grep -E ':(80|443)[[:space:]]'

如果只看到 127.0.0.1:80，说明服务只接受本机请求，外部设备无法直接访问。若配置中明确写了 listen 127.0.0.1:80;，应在确认变更影响后改为适合当前站点的监听地址；如果是其他配置文件覆盖了监听，则先定位重复服务块。

再查看适用的系统防火墙状态。不要在不清楚现有策略时执行清空规则或重置命令：

sudo ufw status verbose

或：

sudo firewall-cmd --state
sudo firewall-cmd --list-all

仅当确认使用对应防火墙、端口当前确实未放行，并且已经记录现有规则时，才添加必要端口。下面的操作会改变服务器入站范围，执行前应确认影响范围；只添加实际使用的端口。

使用 UFW 的系统可以参考：

sudo ufw status numbered
sudo ufw allow 80/tcp

如果该规则是本次新增且需要回滚：

sudo ufw delete allow 80/tcp

使用 firewalld 的系统可以参考：

sudo firewall-cmd --permanent --add-service=http
sudo firewall-cmd --reload

只有在确认 http 服务规则由本次操作添加时，才可以这样回滚：

sudo firewall-cmd --permanent --remove-service=http
sudo firewall-cmd --reload

如果服务器所在平台还有控制台级别的入站访问策略，也要检查其中是否允许 TCP 80；启用 HTTPS 时再检查 TCP 443。不要为了排障临时放开所有端口，验证完成后也不要保留与网站无关的入站规则。

如果网站由应用进程提供内容

如果网站不是直接读取静态文件，而是由应用监听本机端口，Nginx 只负责接收 HTTP 请求并转发到应用。配置示例如下，127.0.0.1:3000 必须替换为应用实际监听地址和端口：

server {
    listen 80;
    server_name example.com;

    location / {
        proxy_pass http://127.0.0.1:3000;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

先绕过 Nginx 检查应用本身：

sudo ss -lntp | grep ':3000'
curl -i http://127.0.0.1:3000/

如果应用本机就无法返回内容，先处理应用服务、监听地址或应用日志，不要通过反复修改 Nginx 配置来掩盖后端问题。如果应用本机正常，而访问 Nginx 返回 502，再检查 proxy_pass 地址、端口、应用是否在 reload 后退出，以及 Nginx 错误日志：

sudo tail -n 50 /var/log/nginx/error.log

应用监听在 127.0.0.1 通常适合由同一台服务器上的 Nginx 转发，应用端口不需要直接对公网开放。这样可以把外部访问入口保持在 Nginx 的 80 或 443 端口。

通过日志确认请求确实命中了目标站点

页面返回 200 后，还要确认请求没有被其他服务块或缓存内容误导。先查看配置中实际定义的日志路径：

sudo nginx -T | grep -nE 'access_log|error_log'

常见日志查看方式如下，实际路径以配置输出为准：

sudo tail -F /var/log/nginx/access.log /var/log/nginx/error.log

在另一个外部终端再次请求：

curl -i http://example.com/

访问日志中应出现对应请求，状态码应与客户端看到的结果一致。重点观察：

• 请求域名是否与目标站点一致；
• 请求路径是否正确；
• 返回状态码是否稳定；
• 错误日志中是否出现权限、文件不存在、连接后端失败等新错误；
• 返回内容是否是当前部署版本，而不是默认页或旧目录内容。

如果页面返回 200，但正文始终是另一套网站，优先检查 server_name 匹配、重复监听配置和 root 路径，不要先修改 DNS 或清理网站文件。

设定回滚条件并结束变更

以下情况应停止继续扩大变更范围，并优先回到上一个已知可用状态：

• nginx -t 失败；
• reload 或首次启动失败，且无法在短时间内定位配置错误；
• 原有站点受到影响，出现大范围 4xx、5xx 或错误页面；
• 本机验证正常，但修改防火墙或监听地址后外部访问全部中断；
• 新增服务块后，原有域名命中了错误站点；
• 后端应用未准备好，却已经把生产流量切换到反向代理配置。

对于新配置文件，回滚时应将它移出 Nginx 当前加载目录，而不是直接删除。以 Debian 或 Ubuntu 的常见布局为例：

sudo mv /etc/nginx/sites-enabled/example.com /root/example.com.nginx.disabled
sudo nginx -t
sudo systemctl reload nginx

如果配置位于 /etc/nginx/conf.d/，则移动对应的 .conf 文件：

sudo mv /etc/nginx/conf.d/example.com.conf /root/example.com.nginx.disabled
sudo nginx -t
sudo systemctl reload nginx

这会使新站点暂时停止加载，但文件仍保留在 /root，需要恢复时可以移回原目录。若修改的是已有配置，应从变更前备份恢复目标文件，恢复后再次执行 nginx -t，确认成功后再 reload。防火墙规则和 DNS 记录也只回滚本次实际新增或修改的内容，不要直接清空整套规则。

首次验证通过后，在约定的观察窗口内继续检查访问日志、错误日志、本机请求和外部请求。只要出现配置检查失败、服务无法保持运行、页面持续返回错误状态码、请求命中错误站点或后端无法连接，就触发回滚；如果响应内容、域名匹配、端口访问和日志状态均符合预期，再保留本次配置并记录最终生效的域名、监听端口、网站目录及回滚文件位置。