Description
最近在调整项目的蓝绿部署，尤其是要使用 lua 脚本动态控制，刚好这块领域不熟悉，于是遇到问题就是咨询 AI，刚好 deepSeek 出来了。在 nginx 配置里面遇到了如下问题：
location ~ ^/aaa/bbb(\.html)?$ {
add_header 'test' 'test';
if ( $request_uri ~* ^.*\.\w+$ ) {
add_header 'Cache-Control' 'max-age=2592000';
}
set_by_lua_file $abc 'xxxx'
content_by_lua_block {
ngx.say('xxx')
}
# 省略其他 lua 脚本
}浏览器访问 /aaa/bbb.html 的时候无法添加 test 这个 header 而把其中的
if ( $request_uri ~* ^.*\.\w+$ ) {
add_header 'Cache-Control' 'max-age=2592000';
}
去掉了之后，访问 /aaa/bbb.html 就有 test 这个header了。当时觉得很纳闷，最后排查了半天以为是 lua 脚本导致的，结果是自己 nginx 使用不熟练，但是为什么会这样呢，于是分别咨询了豆包和 deepSeek。结果分别如下：
豆包返回：
问题分析
- Nginx 处理响应头的顺序
Nginx 在处理请求时，响应头的添加是按照指令在配置文件中的顺序依次执行的。不过，add_header指令的执行可能会受到一些条件的影响，尤其是在if语句块中使用时。- if语句块的影响
在你的配置里，if语句块里的add_header 'Cache-Control' 'max-age=2592000';会对前面已经添加的响应头产生影响。这是因为 Nginx 在执行if语句块时，可能会重新组织响应头，从而造成前面添加的test 头被覆盖或者丢失。- set_by_lua_file指令的异步特性
set_by_lua_file指令是异步执行的，这意味着在执行add_header指令时，$env_var可能还没有被赋值，进而导致无法正确添加 test 头。
解决方案- 调整add_header指令的位置
把add_header指令放到if语句块之后，确保在所有条件判断完成后再添加响应头。解决方案
方案一：调整 if 块的位置
将 if 块移到 content_by_lua_block 之后，确保在添加 test 响应头之后再处理 Cache-Control 响应头。
location ~ ^/aaa/bbb(\.html)?$ {
add_header 'test' 'test';
set_by_lua_file $abc 'xxxx'
content_by_lua_block {
ngx.say('xxx')
}
if ( $request_uri ~* ^.*\.\w+$ ) {
add_header 'Cache-Control' 'max-age=2592000';
}
# 省略其他 lua 脚本
}豆包的看着没有什么问题，先问题分析，给出所有可能，然后再给一个解决方案，看着视乎是对的，修改后的代码也给出来了。但是按照给出的方案是错误的，反复尝试都失败，无奈虽然 deepSeek 经常服务器访问出错，不过还是想试试满血版 R1 效果，结果一用发现震惊：
deepSeek 返回结果：
在Nginx配置中，当使用if指令时，其内部的add_header可能导致外部的add_header失效。这是因为Nginx的if块创建了一个独立的上下文，如果请求匹配了if条件，只有该块内的头部指令会生效，外部的头部指令会被忽略。因此，当访问/aaa/bbb.html时：
存在if块的情况：
请求匹配if条件（URI以扩展名结尾），进入if块。
仅Cache-Control头被添加，外部的test头因未被继承而丢失。
移除if块后：
外部的add_header 'test' 'test'正常执行，test头出现。
解决方案：
避免在if块内使用add_header，改用变量控制：
location ~ ^/aaa/bbb(\.html)?$ {
add_header 'test' 'test';
set $cache_control '';
if ($request_uri ~* \.\w+$) {
set $cache_control 'max-age=2592000';
}
add_header 'Cache-Control' $cache_control;
content_by_lua_block {
ngx.say('xxx')
}
}或在if块内重复添加外部头（不推荐，易冗余）
if ($request_uri ~* \.\w+$) {
add_header 'Cache-Control' 'max-age=2592000';
add_header 'test' 'test'; # 显式添加
}根本原因：Nginx的if块隔离了头部配置，导致外部头在条件成立时失效。通过统一管理头部或规避if内的add_header可解决问题。
看到回复陷入了思考，deepSeek 没有一句废话，直接告诉你哪里出错了，以及怎么修改，简洁明了。不像豆包给出了多种可能得问题，deepSeek 直接告诉你哪里有问题，就像有个人在你问了问题之后，告诉你哪行代码出错了，然后为什么，以及怎么改，排版也很清晰，同时给的方案一用就知道是对的，怪不得最近 deepSeek 如此火爆，关键解决方案正确，并且很清晰。
另外一点值得注意的是 R1 的思考过程相当精彩，可以理解到模型是如何反复思考这个问题，以及里面可能存在的陷阱都一一提出来，比如提到的 Nginx 陷阱和常见错误 你可以直接查看成热打铁，直接学习相关知识。
上面那个问题，可能更多的只是体现 deepSeek 的回答正确性和逻辑清晰性，后续又提问了一个 "网关里面 ALB 来承接外网，内网则用 nginx，这种方式可以吗？是不是常规操作"。结果豆包说了一大堆可行性方面，还有教科书般的内容，比如：
网络隔离与安全：作为外网和内网之间的缓冲地带，ALB 部署在此可以起到初步的安全防护和流量过滤作用。它可以对外网请求进行合法性检查、流量限制等操作，防止恶意流量直接进入内网，增强了整个网络架构的安全性，符合网络安全架构的一般原则。
豆包太教科书了，完全看不懂，而 deepSeek 给出的
(1) 分层安全设计
内网层（NG）：通过 ALB 将合法流量转发到内网的 Nginx（或其他反向代理），内网 NG 可进一步实现细粒度路由、API 网关、服务发现等功能。内网 NG 不直接暴露于公网，降低攻击面。
这就很清晰易懂了，很多了，最后还给了整体的方案设计如下图：
非常详细的对比各个方案差异，以及使用场景，这不是一看就懂了，而且还是表格的形式，给予你最直观的理解可以说太强了。而豆包最后也只是给了一堆教科书的文字说明，没有太多作用，看不明白，徒增困扰。
直观感受，R1 思考深，像和一个聪明人聊天，不需要反复追问，唯一的问题就是思考过程太长，结果等很久，不过看思考的过程也是学习的过程。还有再次追问 token 输出速度会明显下降。基本上现在简单问题都是问豆包，速度快就够了，复杂问题再是问 deepSeek，比如学习一些新知识，比如某个难点。