在美国服务器上排查 Nginx 反向代理不生效，应先把问题拆成四层：请求是否到达目标公网 IP 和端口、Nginx 是否监听该端口、目标 server 配置是否被实际加载，以及 Nginx 能否连接后端应用。不要一开始同时修改 Nginx、防火墙和应用，否则出现异常后很难判断是哪一层造成的。

下面以域名 app.example.com、HTTP 端口 80、后端应用 127.0.0.1:3000 为例。实际操作前，请替换为自己的域名、端口和路径，并保留 SSH 或控制台登录通道，避免防火墙变更影响远程维护。

变更前确认目标和备份

前置条件

开始前应确认以下信息：

• 具备美国服务器的 sudo 或 root 权限。
• 已知域名 app.example.com 当前应解析到哪一个公网 IP。
• 已知后端应用实际监听的地址和端口，例如 127.0.0.1:3000。
• 至少有一个独立于服务器本机的客户端，用于验证公网访问。
• 已确认业务使用 HTTP、HTTPS，或者两者都使用。
• 已确认当前 Nginx 配置文件的位置，不能只凭经验认为一定在某个目录。

先识别操作系统和 Nginx 状态：

cat /etc/os-release
nginx -v
sudo systemctl is-active nginx
sudo nginx -t

如果现有的 nginx -t 已经失败，不要直接进行端口或防火墙变更。应先记录错误信息，避免把原有配置问题和本次变更混在一起。

备份当前配置和生效配置

配置修改前可以执行以下备份。备份内容可能包含证书路径、认证信息或内部地址，应限制为 root 可读。

STAMP=$(date +%Y%m%d-%H%M%S)

sudo cp -a /etc/nginx "/root/nginx-backup-${STAMP}"
sudo nginx -T 2>&1 | sudo tee "/root/nginx-effective-${STAMP}.txt" >/dev/null
sudo chmod 600 "/root/nginx-effective-${STAMP}.txt"

echo "备份目录：/root/nginx-backup-${STAMP}"
echo "生效配置：/root/nginx-effective-${STAMP}.txt"

其中：

• /etc/nginx 是文件层面的备份。
• nginx -T 输出的是 Nginx 解析并加载后的完整配置，包含 include 进来的文件，比只查看正在编辑的文件更适合排查“配置没有生效”的问题。
• 备份目录名中的时间需要记录下来，后续回滚时使用。

先从端口和后端状态查起

确认 Nginx 和后端是否监听

在服务器上执行：

sudo systemctl status nginx --no-pager -l
sudo ss -lntp | grep -E ':(80|443|3000)\b'

输出中的地址和端口需要重点查看：

• 0.0.0.0:80 或 [::]:80：通常表示 Nginx 正在接收对应地址族的 80 端口请求。
• 127.0.0.1:3000：后端应用仅接受本机连接，适合由 Nginx代理。
• 没有 :80：Nginx 没有监听 80，可能是 listen 未配置、配置未加载、Nginx 未启动，或端口被其他进程占用。
• 没有 :3000：后端应用未启动、监听端口不一致，或者实际监听的是其他地址。
• 80 端口显示为 Apache、Caddy 或其他进程：存在端口占用，Nginx 即使配置正确也无法接管该端口。

如果后端提供健康检查接口，先直接从服务器本机访问：

curl -i --connect-timeout 5 http://127.0.0.1:3000/health

如果没有 /health，可以临时访问应用已知的只读路径：

curl -i --connect-timeout 5 http://127.0.0.1:3000/

结果可以按以下方式解释：

如果后端只监听 127.0.0.1:3000，Nginx 的 proxy_pass 应指向 127.0.0.1:3000。如果后端只监听 IPv6 的 [::1]:3000，则不能继续使用 IPv4 的 127.0.0.1:3000，两者必须保持一致。

用生效配置排查“文件写了但没有加载”

查看 Nginx 实际加载了什么

执行：

sudo nginx -T 2>&1 | grep -nE 'configuration file|include[[:space:]]|listen[[:space:]]|server_name[[:space:]]|proxy_pass[[:space:]]'

这条命令只能帮助快速定位，完整结果仍应保留在前面生成的 nginx-effective-时间.txt 文件中。

重点确认以下内容：

1. 目标配置文件是否出现在 nginx -T 输出中。
2. server_name 是否与用户访问的域名完全一致。
3. listen 是否与实际访问端口一致。
4. proxy_pass 是否指向实际可访问的后端地址。
5. 是否存在多个相同域名或多个 default_server。
6. 是否出现 conflicting server name、ignored、duplicate 等警告。

在 Debian 或 Ubuntu 系统中，常见的结构是：

• /etc/nginx/sites-available/：存放配置文件。
• /etc/nginx/sites-enabled/：存放已启用配置的软链接。

配置文件只放在 sites-available 而没有被 sites-enabled 引入时，Nginx 不会自动使用它。确认目标文件确实是新建配置后，才可以建立软链接：

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

如果目标软链接已经存在，不要重复执行。先查看：

sudo ls -l /etc/nginx/sites-available/
sudo ls -l /etc/nginx/sites-enabled/

在其他发行版中，配置可能放在 /etc/nginx/conf.d/，但不能仅凭目录名称判断是否生效。应以 nginx -T 中的 include 结果为准。如果主配置没有包含该目录，新建文件也不会产生作用。

检查典型的 server 冲突

一个常见场景是：配置文件内容正确，但请求被另一个默认虚拟主机接收。可以查看相关配置：

sudo nginx -T 2>&1 | grep -nE 'listen[[:space:]]|server_name[[:space:]]'

需要特别注意：

• 同一个监听地址和端口上，通常只能有一个 default_server。
• 多个 server 块使用相同的 server_name 时，Nginx 可能发出冲突警告，并忽略其中一个。
• 直接使用公网 IP 访问时，未必会匹配 server_name app.example.com，而可能进入默认站点。
• 域名、端口和协议必须同时匹配。访问 https://app.example.com 不会命中只监听 80 端口的 HTTP 配置。

使用明确的反向代理配置

如果目标是把 80 端口的请求转发到本机 3000 端口，可以参考以下 server 块。配置文件名和路径应以当前系统的 include 结构为准。

server {
    listen 80;
    listen [::]:80;

    server_name app.example.com;

    location / {
        proxy_pass http://127.0.0.1:3000;

        proxy_http_version 1.1;
        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;
    }
}

这段配置中：

• listen 80 决定 Nginx 接收哪个端口。
• server_name 决定请求使用哪个虚拟主机。
• proxy_pass 决定请求转发到哪里。
• proxy_set_header Host $host 让后端能够获取原始域名。
• X-Forwarded-For 和 X-Forwarded-Proto 用于传递客户端地址及原始协议。

proxy_pass 末尾是否带 / 会影响 URI 转发方式。例如在 location /api/ 中：

location /api/ {
    proxy_pass http://127.0.0.1:3000;
}

通常会把原始 URI 继续传给后端；如果写成：

location /api/ {
    proxy_pass http://127.0.0.1:3000/;
}

路径可能发生替换。若 Nginx 已经返回来自后端的 404，应同时检查这一点，不要误判为端口或防火墙故障。

如果服务器未启用 IPv6，或者 [::]:80 与现有配置冲突，不要盲目保留两条 listen。先以 nginx -t 的具体错误为准，确认服务器实际需要 IPv4、IPv6，还是两者都需要。

配置检查通过后再加载

编辑完成后，不要直接重启服务，先检查语法和警告：

sudo nginx -t

看到语法成功并不代表所有请求都会命中目标配置，还要关注输出中是否有以下类型的警告：

• conflicting server name
• duplicate
• ignored
• 监听端口冲突相关信息

确认没有影响目标站点的警告后，再执行平滑加载：

sudo nginx -t && sudo systemctl reload nginx

reload 会让 Nginx 重新读取配置，通常比直接 restart 对现有连接的影响更小。nginx -t 失败时，由于使用了 &&，不会继续执行加载动作。

加载后再次确认：

sudo systemctl status nginx --no-pager -l
sudo ss -lntp | grep -E ':(80|443)\b'
sudo journalctl -u nginx -n 50 --no-pager

如果 nginx -t 成功但 reload 失败，应先保留错误信息，不要连续重启。部分服务管理错误与权限、PID 文件或运行目录有关，需根据 systemctl 和日志中的具体内容处理。

从外到内检查防火墙和公网端口

识别服务器上的防火墙

先查看可能使用的防火墙管理工具：

command -v ufw
command -v firewall-cmd
command -v nft

如果使用 UFW：

sudo ufw status numbered
sudo ufw status verbose

只有在确认 HTTP 服务确实需要对公网开放，并且记录了原有规则后，才添加端口规则：

sudo ufw allow 80/tcp
sudo ufw status numbered

HTTPS 使用 443 时，需要针对 443 单独确认规则。不要为了开放 Nginx 而删除或重置整个 UFW 规则集，也不要在未确认 SSH 规则的情况下执行防火墙重置。

如果使用 firewalld，先确认活动区域：

sudo firewall-cmd --get-active-zones
sudo firewall-cmd --zone=public --list-all

下面的 public 只是示例，实际操作应替换成命令输出中的活动区域：

sudo firewall-cmd --zone=public --add-service=http --permanent
sudo firewall-cmd --reload
sudo firewall-cmd --zone=public --list-all

HTTPS 需要检查或添加 https 服务。若系统使用 nftables 直接维护规则，应先查看现有规则：

sudo nft list ruleset

不要在生产服务器上直接执行清空规则集或覆盖整个 nftables 配置的命令。应按照当前发行版使用的规则文件或管理工具进行修改，并保留修改前的规则备份。

区分主机防火墙和上游访问控制

即使 UFW 或 firewalld 已放行，服务器所在平台的入站访问控制也可能仍然拦截 80 或 443。此时需要检查控制台中对应实例或网络边界的入站规则，确认目标端口、协议和来源范围与业务要求一致。

可以从独立客户端测试公网端口：

nc -vz PUBLIC_IP 80

如果客户端没有 nc，可以使用：

curl -v --connect-timeout 5 http://PUBLIC_IP/

结果通常有以下含义：

• timeout：优先检查上游入站规则、主机防火墙、路由或监听地址。
• connection refused：通常表示服务器可达，但目标端口没有进程监听，或被主机明确拒绝。
• 返回 HTTP 状态码：说明请求已经到达 HTTP 服务，应继续检查虚拟主机和反向代理结果。
• 返回默认页面：说明 Nginx 可能工作正常，但请求没有命中预期的 server_name。

后端的 3000 端口通常只需供本机 Nginx 访问，不应为了排查方便就直接对公网开放。除非架构明确要求，否则应保持应用监听在本机地址，并只对外开放实际的 HTTP 或 HTTPS 入口端口。

分层验证 Nginx 是否真正转发

在服务器本机验证指定虚拟主机

即使服务器本机访问 127.0.0.1，也需要通过 Host 头模拟真实域名：

curl -i --connect-timeout 5 \
  -H 'Host: app.example.com' \
  http://127.0.0.1/

如果本机 Nginx 没有响应预期内容，可以按结果判断：

• 404 或默认页面：优先检查 server_name、默认站点和配置加载顺序。
• 502 Bad Gateway：Nginx 已经收到请求，但无法连接后端。
• 504 Gateway Timeout：Nginx 连接后端或等待后端响应超时。
• 返回应用页面或应用预期状态码：Nginx 到后端的转发基本正常。

绕过 DNS 验证公网 IP

为了确认域名当前是否解析到目标美国服务器，可以从独立客户端执行：

curl -v --connect-timeout 5 \
  --resolve app.example.com:80:PUBLIC_IP \
  http://app.example.com/

--resolve 会让这一次请求把域名指向指定 IP，同时仍然保留正确的 Host。这适合区分“公网端口正常但 DNS 指向错误”和“Nginx 或防火墙确实异常”。

如果使用 HTTPS，应使用对应的 443 端口和协议：

curl -v --connect-timeout 5 \
  --resolve app.example.com:443:PUBLIC_IP \
  https://app.example.com/

如果 HTTPS 配置包含证书、SNI 或 HTTP 到 HTTPS 的跳转，应按实际入口验证，不要用普通 HTTP 测试结果替代 HTTPS 结果。

再检查 DNS 当前记录：

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

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

getent ahosts app.example.com

A 记录或 AAAA 记录指向其他地址时，直接修改 Nginx 不会改变用户实际访问的服务器。IPv6 记录存在但服务器未配置 IPv6 监听时，也可能出现部分客户端访问失败，需要将 DNS 记录、服务器监听和防火墙规则一起核对。

对照 Nginx 和后端日志

先从生效配置中确认日志路径：

sudo nginx -T 2>&1 | grep -nE 'access_log|error_log'

然后查看最近记录：

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

如果实际配置使用了自定义日志路径，应以 nginx -T 输出为准。

常见错误信息的判断方式：

• connect() failed (111: Connection refused) while connecting to upstream：后端端口没有监听、端口写错，或后端只监听了其他地址。
• no route to host：可能涉及主机策略、地址族或网络路径。
• upstream timed out：后端未及时响应，需检查应用处理时间和应用日志。
• Nginx 访问日志没有对应请求：请求可能没有到达这台服务器，或命中了其他入口。
• Nginx 有请求但后端没有记录：检查 location、proxy_pass、后端日志位置以及请求是否被 Nginx 在本层直接返回。

如果系统启用了 SELinux，且 Nginx 日志显示连接后端被拒绝，还应查看策略审计信息：

getenforce
sudo ausearch -m AVC -ts recent

不要为了快速验证而长期关闭 SELinux。应先确认是否确实是策略拒绝，再依据系统策略规范进行调整，并在调整后重新执行本机代理测试。

成功标准和观察窗口

一次配置变更至少应同时满足以下条件：

1. sudo nginx -t 成功，且没有与目标站点相关的冲突或忽略警告。
2. ss -lntp 显示 Nginx 正在监听实际入口端口。
3. 直接访问后端地址能够得到预期响应，或已确认后端的失败属于应用自身问题。
4. 使用 Host 头访问本机 Nginx 时，能够看到后端响应或明确的应用状态码。
5. 从独立客户端访问公网 IP 时，能够连接到正确端口。
6. 使用 --resolve 访问域名时，能够命中目标 server_name。
7. Nginx 访问日志和后端应用日志能够对应同一笔请求。
8. 真实域名访问结果与预期一致，未出现新增的 502、504、连接超时或错误跳转。

变更完成后，应按照业务约定保留观察窗口，至少覆盖一次真实访问和现有监控检查周期。观察期间不要继续修改多个配置项，否则异常无法归因。重点观察 Nginx 错误日志、后端错误率、连接超时以及访问是否仍然落到默认站点。

回滚条件和操作

出现以下情况时，应停止继续试错并考虑回滚：

• 新配置导致 nginx -t 失败。
• 加载后公网入口从可访问变为超时或拒绝连接。
• 目标站点持续出现 502、504，且后端本身原本正常。
• 请求被错误地转发到其他应用或默认站点，影响范围扩大。
• 防火墙变更影响 SSH 或其他既有业务端口。
• 无法确认某项修改会对现有虚拟主机产生什么影响。

如果本次只是新建了一个软链接，并且确认该软链接是本次变更创建的，可以删除该软链接，不要删除目标配置文件：

sudo test -L /etc/nginx/sites-enabled/app.example.com
sudo rm /etc/nginx/sites-enabled/app.example.com

如果本次修改了已有配置文件，应从备份中恢复对应文件。下面的路径和时间戳需要替换为实际备份位置：

sudo cp -a \
  /root/nginx-backup-YYYYMMDD-HHMMSS/sites-available/app.example.com \
  /etc/nginx/sites-available/app.example.com

恢复前应再次备份当前文件，避免回滚过程覆盖了最新排查信息。恢复后执行：

sudo nginx -t && sudo systemctl reload nginx

如果本次新增了 UFW 规则，只能在确认该规则确实由本次变更创建、且没有其他业务依赖时删除：

sudo ufw delete allow 80/tcp

firewalld 也应只撤销本次新增的服务规则：

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

回滚完成后，重新验证后端直连、本机 Host 访问和外部公网访问。若 nginx -t 失败，通常不应继续强制加载；先恢复到最后一个已知可用配置，再根据错误日志单独处理端口、虚拟主机或后端连接问题。