Nginx 网站服务核对：进程、监听、配置来源与请求路径

先对应查询的程序、候选进程与运行环境

先记录要检查的网站、故障时间，以及当前终端位于宿主系统、虚拟机还是容器内。确认 PATH 中的 nginx 是本次要查询的可信程序后再使用版本命令；本文以 Nginx 1.28.0、procps-ng v4.0.5、iproute2 v6.12.0 和 systemd v257 的固定资料解释相关字段。

nginx -v 只显示所调用程序的版本，-V 还显示编译器与构建参数。它们不证明这个程序就是当前运行的 master，也不能单独说明实际启动时采用了哪个配置文件、前缀或全局参数；安装目录中存在多个版本时尤其要先对应真实部署。

ps -C nginx 按进程的可执行名称匹配，不按完整命令行搜索。下面只显示 PID、父 PID 和名称，用于取得候选进程及父子关系；可见结果受当前进程视图和权限影响，空结果不能直接证明所有容器或主机上都没有 Nginx。

Nginx 通常由 master 读取配置并管理 worker，由 worker 处理请求。把候选 PID 与实际管理器或容器的进程记录对应起来，再判断它属于哪个实例；不要仅凭名称相同、进程存在或版本输出就确认网站已经正常。

nginx -v
nginx -V
ps -C nginx -o pid,ppid,comm

只向实际管理者读取限定的服务属性

systemctl 用于 systemd 系统与服务管理器，并不是所有 Linux 环境都适用。只有确认当前实例由系统级 systemd 管理、实际单元名确为 nginx.service 时，才使用下面的示例；其他单元名、用户级服务或容器管理方式应对应其真实管理记录，不能强套这个名字。

LoadState 描述单元配置的加载状态，ActiveState 和 SubState 描述管理器所知的运行状态；MainPID 用于与首节候选进程对应。单元处于活动状态，不等于正确网站、证书和上游应用已经可用，也不能只凭一个 PID 判断全部 worker 的工作情况。

FragmentPath 和 DropInPaths 帮助定位单元文件及覆盖文件来源。systemctl show 展示的是管理器的属性，不是 Nginx 进程内存中的配置；systemctl cat 展示磁盘上的单元文件，它也可能与管理器已读取的版本不同。

本例只取必要字段，不导出环境、完整单元内容或启动命令。属性缺失、单元未找到和管理器无法连接应分别记录，再确认管理方式；不要把这些情况直接当作网站故障并立即重启。

systemctl show nginx.service --no-pager \
  --property=Id,LoadState,ActiveState,SubState,MainPID \
  --property=FragmentPath,DropInPaths

分别核对 TCP、UDP 与当前网络命名空间

先确认当前网络命名空间与目标 Nginx 实例一致，再观察 socket。ss 的 -l 选择监听条目，-n 使用数字形式，-t 与 -u 分别选择 TCP 和 UDP，-p 尝试显示使用该 socket 的进程；权限不足时，进程信息可能不完整。

将实际本地地址、端口和可见进程与网站入口配置对应起来，不预设所有站点都使用同一端口。TCP 列表不能替代 UDP 检查，UDP 条目存在也不能证明已经启用或正确处理 QUIC、HTTP/3；还要核对实际 Nginx 模块及监听配置。

普通 ss 查询不会自动进入另一个容器的网络命名空间。容器内部端口、宿主机发布端口和外部入口可能不同，应分别找到对应的观察位置，而不是因当前列表没有目标端口就宣布所有入口都未监听。

监听存在只说明这一层的 socket 状态，不能证明安全组、防火墙、域名入口、TLS 或上游服务可达。若外部访问失败，先把这些层次分开；本例不使用关闭 socket 或切换命名空间的选项。

ss -lntp
ss -lnup

追踪配置来源，区分文件检查与运行配置

从实际启动方式查清所用程序及配置来源，再核对 -c 指定的配置文件、-p 指定的前缀和 -g 提供的全局指令。构建参数中的默认路径只是线索；由面板、容器或其他流程生成配置时，还要确认生成来源及实际引用的文件，不能猜一个常见目录就是当前配置。

磁盘文件已经修改，不代表运行中的 worker 已采用它。应把配置版本、管理流程中的加载记录和当前请求行为对应起来；配置测试成功也不是已生效证明，更不能替代对目标站点和上游的检查。

nginx -t 会检查配置语法并尝试打开配置引用的文件。Nginx 1.28.0 的测试路径还涉及 PID 文件、目录和日志文件的打开或创建，因此它不是只读查看文本，也不能无条件承诺没有文件系统影响。应在确认程序、配置来源、权限和影响范围后，把测试作为单独的受控步骤。

nginx -T 在配置测试之外还会把配置文件输出到标准输出。配置可能包含敏感请求头、上游凭据或内部地址，不应直接导出到公开日志；本教程不提供执行 -t 或 -T 的复制块，也不读取未知路径下的完整配置。

沿地址、名称、location 和上游追踪请求路径

先将实际入口地址和端口对应到 listen 配置，再检查默认 server 与目标 server_name。默认 server 属于地址和端口这一组监听配置，并不是给 server_name 起一个特殊名称就能指定；请求没有匹配到预期名称时，可能由该监听组的默认站点处理。

HTTPS 还要区分 TLS 握手中的 SNI 与 HTTP 请求中的 Host。Nginx 会在不同处理阶段选择相关 server 配置；只访问 IP 再修改 Host，并不等于使用真实域名完成了同样的证书核名和 SNI 检查。

在选定 server 后，对应实际 URI 与 location。精确匹配、前缀、正则和 ^~ 的规则不同，不能只找一个最长前缀就停止；查询参数也不应被误当作 location 路径本身。若发生内部跳转，后续处理位置还可能改变。

静态请求要分清 root 拼接 URI 与 alias 替换 location 路径的方式；代理请求则核对 proxy_pass 的协议、目标和是否包含 URI。带不带 URI 会影响上游路径的形成，不能只凭浏览器地址猜测上游实际收到什么。这里只对照已有配置，不生成新的站点、文件路径或代理目标。

先明确请求目的，再评审 HTTP 核验步骤

主动请求与前面的状态查询不同。先由网站管理者确认真实 URL、允许的方法、路径用途和检查时间窗口，再决定是否使用 curl。-I 或 --head 发出 HEAD 请求，只取响应头，不能证明 GET 正文、页面资源或完整业务流程正常；HTTP 安全方法也仍可能产生访问日志、计费或实现层面的副作用。

curl 8.12.1 的 -q 必须放在首个参数位置才会跳过默认 curlrc。按检查目标确认代理路径：只有获准进行直连核对时才使用 --noproxy '*'；它会改变是否经过代理的路径，不能把直连结果与原有代理入口混为一谈。

需要核对指定入口地址时，本次核验应使用 --resolve 对真实域名和端口做精确映射，URL 仍应保留真实域名。证书核名依据 URL 中的主机名，HTTP Host 又处于另一处理阶段；不能用 IP URL 加自定义 Host 来替代同等的 HTTPS 域名核验，也不以跳过证书验证来制造成功结果。

为单次请求分别设置连接阶段与整个传输的超时，连接阶段包含名称解析及所需握手。不要自动跟随跳转或反复重试，以免扩大访问范围；分别记录 curl 退出码、HTTP 状态、发生时间及实际服务端记录，因为默认情况下 HTTP 错误状态不一定让 curl 返回失败。

下面是全部为注释的离线操作清单，不包含目标 URL、IP、凭据或可执行请求模板。实际请求由获准操作另行执行，完成后仍需回到对应站点、上游和日志验证观察到的结果。

# 先确认获准的 URL、方法、端口和检查时间窗。
# -I / --head：发出 HEAD 请求，只读取响应头。
# -q：必须放在首位，跳过默认 curlrc。
# --noproxy '*'：仅用于获准的直连路径核对。
# --resolve：精确映射域名与端口，URL 保留域名。
# --connect-timeout：限制连接阶段时间。
# --max-time：限制整个传输时间。
# 保留 TLS 校验，不自动跟随跳转或重试。
# 分开记录 curl 退出码、HTTP 状态和对应日志。

用真实日志与业务时间完成逐层核对

从实际配置与管理方式确定 access_log 和 error_log 的目的地，不默认日志一定在某个目录，也不直接读取不明路径。访问日志可以使用不同格式、关闭、按条件记录或缓冲写入；没有立即看到一行记录，并不能单独证明请求没有到达。

Nginx 访问日志按请求处理结束时的 location 上下文记录，内部跳转后可能不同于最初匹配的位置。应将获准请求的时间、目标名称和状态与对应日志联系起来，必要时再由上游管理者对照其记录；一个响应头或单个状态码不足以证明整个请求链正确。

看不到进程或监听时，先回到实例、管理者和命名空间；能监听却未得到预期站点时，继续核对入口、TLS、名称和 location；已经到达正确站点但业务失败时，再对照上游路径、应用错误和资源现象。这些步骤用于缩小范围，不把某一种现象直接指定为唯一根因。

相关阅读中的 UFW 教程用于核对主机访问控制，Linux 资源教程用于核对内存、负载、磁盘与容器观察范围。确需修改配置或恢复服务时，先保存必要的脱敏记录、确认维护窗口与管理恢复入口，再按实际部署流程操作，并重新验证目标网站和上游业务。