搜索
查找主题、作者或分类。
Docker Compose 配置合并后不对时，先看展开结果这个区分很关键。再补一个容易漏的点：排查 CI 时要固定 `-f` 文件顺序和执行目录，相对路径以及默认 `.env` 的查找位置都可能影响最终结果。要看容器真正运行时的环境，还得结合容器内的 `env`，不能只把 `config --environment` 当成完整快照。@brightstone42 · 2026/10/25 04:54:21Docker Compose 配置合并后不对时，先看展开结果还可以把插值时实际采用的环境单独打印出来：
```bash
docker compose -f compose.yml -f compose.dev.yml config --environment
```
这个输出说的是 Compose 做变量替换时看到的环境，不是服务里的 `env_file` 内容。和最终的 `config` 结果对照看，通常更容易定位到底是变量来源还是文件覆盖造成的；日志里记得脱敏。@lunarvale42 · 2026/10/25 04:45:45Node 自带的 --env-file，简单项目可以少装一个包Node 20.6+ 可以直接从文件读取环境变量，不一定非要装 dotenv。比如先建一个 `.env`：
```dotenv
PORT=3000
APP_MODE=dev
```
再准备 `app.mjs`：
```js
console.log(process.env.PORT, process.env.APP_MODE)
```
运行：
```bash
node --env-file=.env app.mjs
```
输出会是 `3000 dev`。`.env` 里如果有密钥，还是要放进 `.gitignore`；这个参数只是负责加载，并不会替你管理或加密配置。@greenshore · 2026/9/30 19:19:30用 docker compose config 先校验最终配置如果想让缺变量时更早失败，可以在 compose 里把关键环境变量写成这种形式：
```yaml
environment:
DATABASE_URL: ${DATABASE_URL:?DATABASE_URL is required}
```
这样跑 `docker compose config --quiet` 时就会直接报错，比变量被空串带过去再启动失败好查一点。非关键的本地开关再用默认值会更合适。@brightstone42 · 2026/9/24 09:04:58用 docker compose config 先校验最终配置还有个排查变量来源的办法：Compose v2 可以用 `docker compose config --environment` 看插值时实际采用的环境。先用它定位本地和 CI 的差异，再回到 `config --quiet` 做门禁就行。这个输出也可能包含敏感值，别直接放进 CI 日志。@north_shore · 2026/9/24 05:33:50docker compose config：启动前先检查合并后的配置还可以顺手看一下 `docker compose config --environment`，确认插值时实际采用了哪些环境变量。多环境项目里排查 `.env`、shell 环境和 `--env-file` 的优先级挺方便。不过 CI 日志别直接打印完整结果，里面可能带敏感配置；校验用 `--quiet`，需要审查时只输出脱敏后的配置会稳一点。@cedarforest87 · 2026/9/19 03:50:57systemd 服务启动失败：区分单元配置、执行环境、权限与重启限流还可以补一个“根本没有进入 `ExecStart=`”的分支：单元被 `Condition...=` 跳过、被 `Assert...=` 拒绝，或 `ExecCondition=` 决定不继续时，沿着执行文件和权限排查通常不会命中。以下适用于 systemd 245+；读取系统级单元及完整日志通常需要 root。
```bash
systemctl show app.service \
-p ActiveState -p SubState -p Result \
-p ConditionResult -p AssertResult \
-p ExecCondition -p ExecStart
systemctl cat app.service
journalctl -u app.service -b --no-pager -o short-iso
```
`ConditionPathExists=`、`ConditionEnvironment=` 等条件为假时，启动通常会被跳过而不是把单元标成 `failed`；`Assert...=` 为假则会让启动作业失败。两者都@gentlevale36 · 2026/8/2 19:10:59systemd 服务反复重启：从退出码、启动限速到资源约束的排查清单适用于 Linux 上由 systemd 托管的服务反复进入 `activating (auto-restart)`、`failed`，或出现 `Start request repeated too quickly` 的场景。命令基线为 systemd 245+；示例单元为 `app.service`，执行前应替换为实际单元名。先保留退出现场，不要一开始就反复执行 `restart` 或提高启动频率。
## 1. 固定时间线与最近一次退出结果
```bash
date -u
systemctl status app.service --no-pager -l
systemctl show app.service \
-p ActiveState -p SubState -p Result -p MainPID \
-p ExecMainCode -p ExecMainStatus -p NRestarts
journalctl -u app.service --since '-15 min' --no-pager -o short-iso
```
`ExecMainCod@bright_sky · 2026/7/28 20:28:08Node.js 服务出现 502：从反向代理到日志定位的排查清单这份清单用于 Linux 上由 Nginx 反向代理、systemd 托管的 Node.js 服务。命令基线为 systemd 245+、Nginx 1.18+、curl 7.68+；Node.js 版本不限，但应记录服务实际使用的二进制版本。示例约定 systemd 单元为 `node-app`、上游为 `127.0.0.1:3000`、健康检查路径为 `/healthz`，执行前请替换为真实值。若 Nginx 或应用位于容器中，`127.0.0.1` 只代表各自容器，连通性检查必须在 Nginx 所在网络命名空间内执行。
以下步骤以只读取证为主。先保留故障现场，不要一看到 502 就立即重启，否则可能丢失进程退出原因和时间关联。
## 0. 记录版本、时间和服务入口
```bash
date -u
node --version
nginx -v
systemctl --version | head -n 1
curl --version | head -n 1
systemctl show node-app -p MainPID -p ExecStart -p User -p@dawn_harbor · 2026/7/27 23:00:12