add_header默认仅在200、201、204、206、301–304、307、308等状态码下生效，4xx/5xx错误响应中不输出；加always参数可强制所有状态码（含400、401、500、302、304）均发送指定响应头。
add_header 不生效？先看状态码范围
默认情况下，add_header 只对 200、201、204、206、301–304、307、308 这些响应状态码生效。如果你的接口返回 400、401、500 等错误码，自定义 Header 就不会出现在响应里——这是最常被忽略的行为。
常见错误现象：用 curl 测试正常接口能看到 X-Env，但一触发登录失败（401）或参数校验失败（400），Header 就消失了。
- 不加
always：适合只在成功响应中透出的业务标识，比如X-Request-ID - 加
always：适合调试类 Header（如X-Backend、X-Route）或监控埋点 - 注意安全限制：像
Set-Cookie这类敏感 Header 加了always可能被浏览器拒绝，得结合业务判断是否真需要强制透出
location 里写 add_header 覆盖 server 级配置
add_header 在 location 块中声明时，会覆盖同名的 server 级配置，而不是合并。没声明则继承上级，但一旦出现同名，上级就失效。
使用场景：给 API 路径单独加调试 Header，而静态资源路径不需要。
- 若
server块写了add_header X-Service "web"，又在location /api/里写了add_header X-Service "backend"，那么所有/api/下的响应只会带"backend" - 想复用多个 Header？别重复写一堆
add_header，改用map预定义变量（见下一条） - 避免在多个
location中零散写相同 Header，容易漏配或冲突
多域名差异化 Header 用 map 而不是硬写 server 块
当有 api.example.com、admin.example.com、docs.example.com 等多个子域名时，直接在每个 server 块里重复写 add_header X-Service "xxx" 难维护且易错。
推荐做法是在 http 块顶部用 map 定义变量：
Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq（Cortex‑A9/A53 + FPGA）Linux 环境，调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查，支持 PetaLinux 开发。
map $host $x_service {
api.example.com "api";
admin.example.com "admin";
docs.example.com "docs";
default "unknown";
}
然后在任意 server 或 location 中复用：
add_header X-Service $x_service always;
-
map是惰性求值，只在实际用到时解析，性能无负担 - 所有域名共用同一份逻辑，增减子域名只需改
map表，不用动每个server - 注意
map必须放在http块顶层，不能嵌套在server或location里
配置生效前必须 nginx -t && nginx -s reload
修改完 nginx.conf 或包含文件后，不校验直接 reload 可能导致服务中断。
实操步骤：
- 运行
nginx -t检查语法，输出test is successful才算通过 - 确认配置路径：如果用了非默认路径（如
/opt/nginx/conf/nginx.conf），需显式指定nginx -t -c /opt/nginx/conf/nginx.conf - reload 命令是
nginx -s reload，不是systemctl reload nginx（后者依赖 systemd 配置，可能指向旧二进制） - 某些容器环境（如你知识库提到的
kd-cosmic-xk）需重启对应 pod，nginx -s reload无效
最容易被忽略的是：改了 conf.d/ 下某个子配置，却忘了它被 include 在主配置里——nginx -t 会一并检查，但人容易只盯 nginx.conf 主文件。
