Nginx同名配置项按作用域和优先级生效：log_format仅限http块，access_log和proxy_set_header多级覆盖，types中后加载者胜出，server_name+listen组合须唯一，location匹配依修饰符优先级而非书写顺序。
同名配置项在 Nginx 中不一定会“报错”，但会按明确的继承与覆盖规则生效——关键看它出现在哪个配置块（context）、是否允许多次定义、以及加载顺序。处理冲突不是删掉重复项，而是理清作用域和优先级。
指令作用域决定能否共存
有些指令只能出现在特定层级，写错位置直接报错；有些则允许多次出现，后定义覆盖前定义：
-
log_format 只能在
http块中定义，写进server或location会启动失败 -
access_log 可在
http、server、location中都出现，location内的设置会覆盖server级的，server级又覆盖http级 -
proxy_set_header 同样支持多级定义，但必须写在生效的
location或server块内，写在http根层级对代理请求无效
types 块中的 MIME 类型重复会静默覆盖
Nginx 合并所有 types { } 块为一张哈希表，同一后缀被多次定义时，以最后加载的为准：
- 若
/etc/nginx/mime.types定义application/javascript js;，而你自定义的custom.mime又写了text/plain js;，且include custom.mime;在include mime.types;之后 → 最终.js被识别为text/plain，脚本无法执行 - 正确做法：自定义文件只补缺，不重定义已有后缀；如需覆盖，确保
include顺序清晰，并加注释说明
server_name + listen 组合必须唯一
这不是“指令冲突”，而是路由逻辑冲突。Nginx 要靠 listen 和 server_name 共同标识一个服务入口：
- 两个
server块同时写listen 80;和server_name example.com;→ 启动时警告conflicting server name "example.com" on 0.0.0.0:80, ignored，后者被忽略 - 解决方式不是删一个，而是检查用途：是测试环境？用不同子域名（
test.example.com）；是 HTTPS/HTTP 分离？确保listen 443 ssl;和listen 80;分属不同server块
location 匹配不看“谁先写”，而看修饰符优先级
多个 location 块针对同一 URI，生效的不是第一个，而是符合匹配规则中最高优先级的那个：
-
location = /api（精确匹配） >location ^~ /api/v1（前缀强制终止） >location ~ \.php$（正则） >location /api（普通前缀） - 常见误操作：在
location /下写了proxy_pass，又在同级加了location /static却没加^~，结果因普通前缀最长匹配，/static/css/app.css还是进了/的代理块 - 建议：静态资源用
^~ /static/显式拦截，避免落入后端；正则 location 尽量放后面，且确保第一个匹配足够精准
