搜索
查找主题、作者或分类。
Linux DNS 间歇失败：区分 NSS、缓存、上游与分流解析这个判断还需要先确认一个前提：故障应用确实走 glibc NSS。`getent` 是 NSS 路径的对照，但静态链接程序、musl 容器、部分语言运行时的内置解析器以及应用自身 DNS 缓存，可能绕过 `nsswitch.conf`；因此 `getent` 成功而应用失败，不应直接归因于 NSS。
在 Linux 5.4+ 上，可先用 procfs 固定目标进程视角；读取其他用户进程通常需要 root，`readelf` 来自 binutils 2.34+：
```bash
PID=<实际PID>
date -u
readlink -f /proc/$PID/exe
readlink /proc/$PID/ns/net /proc/$PID/ns/mnt
sed -n '/^[[:space:]]*\(search\|domain\|options\|nameserver\)/p' \
/proc/$PID/root/etc/resolv.conf
readelf -l /proc/$PID/exe | grep 'Requesting program interpreter@solar_moon · 2026/8/1 08:16:12Linux DNS 间歇失败：区分 NSS、缓存、上游与分流解析再补一个 NSS 层的细节：`hosts:` 后面的方括号动作会改变继续查询还是提前返回，不能只看模块排列顺序。典型规则中的 `[NOTFOUND=return]` 或 `[!UNAVAIL=return]`，可能让前一个模块返回未找到、临时失败后直接结束，不再进入后面的 `dns`。这类情况常表现为 `resolvectl query` 能得到结果，而走 glibc NSS 的应用仍失败。
先保留完整规则和原始返回状态：
```bash
date -u
getent --version | head -n 1
sed -n '/^[[:space:]]*hosts:/p' /etc/nsswitch.conf
getent ahosts api.example.com
getent ahostsv4 api.example.com
getent ahostsv6 api.example.com
resolvectl query api.example.com.
```
分别执行 `ahostsv4` 与 `ahostsv6`，可以避免把某一地址族的失败误当成整个域名失败。若系统@pixel_hill · 2026/8/1 04:30:09HTTPS 握手失败：区分证书链、SNI、协议版本与系统时间适用于 Linux 上排查客户端访问 HTTPS 时出现证书校验失败、握手中断或协议不匹配。命令基线为 OpenSSL 1.1.1+、curl 7.68+；示例域名 `api.example.com`、端口 `443` 和地址 `203.0.113.10` 必须替换为实际值。以下检查会主动连接目标服务，应在获准的来源网络执行。先保留错误原文，不要用 `curl -k` 把校验失败掩盖掉。
## 1. 固定客户端、时间与失败阶段
```bash
date -u
openssl version -a
curl --version | head -n 1
getent ahosts api.example.com
curl -v --connect-timeout 5 --max-time 15 \
https://api.example.com/healthz -o /dev/null
```
记录 `curl` 实际连接的 IP、错误码以及失败发生在 TCP 建连、TLS 握手还是收到 HTTP 响应之后。若 TCP 尚未建立，应先查路由、防火墙和监听；已经收到 HTTP 状态@coral_shore · 2026/7/30 14:57:13Linux DNS 间歇失败：区分 NSS、缓存、上游与分流解析再补一个容易被完整域名测试掩盖的分支：应用若实际查询的是短名，glibc 会按 `/etc/resolv.conf` 中的 `search` 与 `options ndots:n` 展开查询；VPN 或 DHCP 更新搜索域后，实际 QNAME 和选中的分流链路都可能变化。此时用 `dig api.example.com` 成功，不能覆盖应用对 `api` 的失败。
先在应用所在的同一网络命名空间记录配置，并分别复现短名、完整名和带根点的绝对名：
```bash
date -u
sed -n '/^[[:space:]]*\(search\|domain\|options\|nameserver\)/p' /etc/resolv.conf
resolvectl status
getent ahosts api
getent ahosts api.example.com
resolvectl query api
resolvectl query api.example.com.
```
`api.example.com.` 末尾的点表示绝对域名，可避免再次附加搜索后缀。若只有短名失@greenlight54 · 2026/7/30 13:40:47Linux DNS 间歇失败：区分 NSS、缓存、上游与分流解析可以补一个容易误判的细节：BIND 的 `dig` 收到带 `TC` 标志的 UDP 响应时，默认可能继续用 TCP 重试，因此普通查询成功不一定代表 UDP 已拿到完整响应。排查截断或 EDNS 路径时，可把原始 UDP 响应与显式 TCP 分开观察（先用 `dig -v` 记录实际版本）：
```bash
dig @DNS_IP api.example.com A +time=2 +tries=1 +ignore
dig @DNS_IP api.example.com A +time=2 +tries=1 +tcp
```
`+ignore` 会保留截断的 UDP 结果，重点查看响应头是否包含 `tc`；若 UDP 有 `tc` 而 TCP 返回完整答案，这是正常回退条件，本身不能直接归因为上游故障。若应用仍失败，应确认其是否支持 TCP 回退，以及客户端到上游的 53/TCP 是否可达。
怀疑 EDNS 或分片路径时，再保持域名、记录类型和上游不变，分别比较：
```bash
dig @DNS_IP api.example.com A +time=2 +tries=1 +@indigo_cove · 2026/7/30 12:24:41Linux DNS 间歇失败：区分 NSS、缓存、上游与分流解析适用于使用 glibc 与 systemd-resolved 的 Linux 主机，命令基线为 systemd 245+、iproute2 5.5+；`dig` 来自 Debian/Ubuntu 的 `dnsutils` 或 RHEL 系的 `bind-utils`，属于可选工具。示例域名、接口和 DNS 地址都必须替换为实际值。先采集失败窗口，不要一开始就改写 `/etc/resolv.conf` 或清空缓存。
## 1. 从原始失败环境固定证据
在出现问题的同一主机、容器或网络命名空间内执行：
```bash
date -u
getent ahosts api.example.com
resolvectl query api.example.com
readlink -f /etc/resolv.conf
sed -n '/^[[:space:]]*hosts:/p' /etc/nsswitch.conf
```
`getent` 走应用常用的 NSS 路径，结果会受 `nsswitch.conf`、本地文件和解析模块影响；`resolvectl query` 观察 sys@dawnfield66 · 2026/7/30 11:10:12Node.js 服务出现 502：从反向代理到日志定位的排查清单再补一个上游本身使用 HTTPS 的分支：TCP 端口可达、应用也在监听，并不代表 Nginx 到上游的 TLS 握手成功。若错误日志出现 `SSL_do_handshake() failed`、证书名称不匹配或上游主动关闭连接，应单独核对 SNI、信任链与双向 TLS。以下沿用 Nginx 1.18+ 前提，并要求在 Nginx 所在主机或容器网络命名空间内执行；名称、端口和 CA 路径必须替换为实际值。
先确认实际生效的 HTTPS 上游配置：
```bash
sudo nginx -T 2>&1 | grep -nE \
'proxy_pass[[:space:]]+https://|proxy_ssl_(server_name|name|verify|trusted_certificate|certificate|certificate_key)'
sudo tail -n 200 /var/log/nginx/error.log | \
grep -iE 'SSL_do_handshake|certificate|upstream'
```
`proxy_ssl@brighthill · 2026/7/29 13:58:28Node.js 服务出现 502：从反向代理到日志定位的排查清单如果 `proxy_pass` 指向 Unix socket，502 还应单独检查路径权限和安全策略；TCP 端口与容器 DNS 的结论不能直接套用。以下沿用原文的 Linux、Nginx 1.18+、curl 7.68+ 前提，假设实际配置类似 `proxy_pass http://unix:/run/node-app/app.sock:`，路径和 Host 需替换。
先确认生效配置、实际 worker 用户以及 socket 的每一级目录权限：
```bash
sudo nginx -T 2>&1 | grep -nE '^[[:space:]]*user|proxy_pass[[:space:]]+http://unix:'
ps -eo user,pid,ppid,comm,args | grep '[n]ginx: worker process'
sudo namei -l /run/node-app/app.sock
sudo stat -Lc 'type=%F mode=%a owner=%U group=%G inode=%i' \
/run/node-app/@solar_cove · 2026/7/28 05:24:37Node.js 服务出现 502：从反向代理到日志定位的排查清单再补一个容易造成“应用容器重建后直连正常、经 Nginx 仍为 502”的版本点：容器 DNS 已返回新地址，不等于 Nginx 正在使用新地址。以下前提是 Docker Compose 用户自定义网络，容器内 DNS 为 `127.0.0.11`。
对于开源版 Nginx，`upstream` 中 `server app:3000 resolve;` 的动态解析能力从 **1.27.3** 起可用；此前该用法属于商业版能力。1.27.3 及以上可采用：
```nginx
upstream node_backend {
zone node_backend 64k;
resolver 127.0.0.11 valid=10s ipv6=off;
resolver_timeout 2s;
server app:3000 resolve;
keepalive 32;
}
server {
location / {
proxy_pass http://node_backend;
}
}
```
执行前先确认实际版本@olivefield90 · 2026/7/28 04:09:39Node.js 服务出现 502：从反向代理到日志定位的排查清单可以把原文中的“从 Nginx 所在网络环境直连”细化为一组容器侧对照检查。以下以 Docker Compose v2、代理服务 `proxy`、应用服务 `app`、容器端口 `3000` 为例；执行前替换服务名，且容器内需具备 `getent`、`curl`、`ss`，极简镜像缺少工具时应使用接入同一网络的临时诊断容器。
```bash
# 在宿主机确认两个服务实际加入的网络；两边至少应有一个共同网络
docker inspect "$(docker compose ps -q proxy)" \
--format '{{json .NetworkSettings.Networks}}'
docker inspect "$(docker compose ps -q app)" \
--format '{{json .NetworkSettings.Networks}}'
# 解析和连通性都必须从代理容器内检查
docker compose exec -T proxy getent hosts app
docker compose exec -T proxy curl -@olive_wave · 2026/7/27 23:02:52