Nginx自定义请求头head失效问题

最新推荐文章于 2025-05-09 15:55:44 发布
原创 最新推荐文章于 2025-05-09 15:55:44 发布 · 1.7k 阅读 · 2 ·
CC 4.0 BY-SA版权
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
文章标签：

#nginx

在配置Nginx做转发的时候，踩了一个不错的坑，这个坑是这样的，后端在获取请求头的值得时候，一直取到的是null，比如java

httpRequest.getHeader("jwt_token")

这个一直返回null，原因是Nginx的配置

underscores_in_headers

这个值默认是off，表示请求头如果带下划线默认是忽略掉的，恰巧自定义的请求头就是带了下划线，这是后需要配置为：

underscores_in_headers on;

 

具体原因：去看Nginx源码吧。

保障服务永不停歇：Nginx负载均衡中的健康检查与故障转移策略
墨夶的博客
12-11 1124
Nginx是一款开源软件，最初由俄罗斯程序员Igor Sysoev开发，旨在解决C10k问题（即同时处理1万个并发连接）。它采用了事件驱动型非阻塞架构，使得单台服务器能够轻松应对海量请求。除了基本的HTTP服务外，Nginx还广泛应用于反向代理、静态资源分发、动态内容缓存以及SSL/TLS终止等领域。更重要的是，Nginx内置了强大的负载均衡功能，可以帮助我们合理分配流量，提高整体系统的可用性。
Nginx配置完毕后不准发请求头header的解决办法
qq_14945327的博客
11-07 1175
目前项目架构是vue+springboot前后端分离的，前端部署在nginx上，后端启动接口服务，并用nginx进行反向代理 部署完毕后，后端就是怎么收取不到shiro的header中的token，并且我们的token定义为AUTH_TOKEN，查看了后端日志+nginx就是怎么也收不到 nginx配置里只有转发设置原始ip和host的 proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; prox
nginx反向代理proxy_set_header自定义header头无效的问题
weixin_34221276的博客
11-12 2908
###案例1 环境nginx,linux,tomcat 域名访问是走nginx给后端服务器处理的， 问题是域名经过nginx访问直接不能获取到headers,直接tomcat访问可以 那么问题肯定在nginx上无法处理headers的问题了， 经过查询上面资料得到是nginx的锅,hearders有下划线的锅，nginx设置underscores_in_...
nginx：在Nginx中如何为请求添加自定义HTTP头
最新发布
weixin_43290370的博客
05-09 1526
问题场景当需要添加数十个自定义头时，如何避免性能下降。阿里云解决方案头合并技术default "";# 减少重复处理Lua动态生成}, ",")end性能对比数据| 方案 | 请求处理延迟 | 内存占用 | 适用场景 || 原生add_header | +0.2ms | 低 | 简单头添加 || map变量 | +0.5ms | 中 | 条件头添加 |
通过Nginx的proxy_set_header设置请求头无效
weixin_44798288的博客
12-15 6330
nginx header参数无效
nginx转发导致请求头header失效问题
weixin_39303215的博客
08-15 1962
遇到请求头失效问题的排查
Nginx自定义请求头丢失
weixin_41558221的博客
05-17 945
Nginx丢失带下划线的自定义请求头问题
win10 Nginx 添加自定义头未生效
小张的博客
07-30 727
其他配置未生效也可以试一下 nginx运行时修改了配置文件需要添加请求头或响应头 使用 nginx -s reload 后发现配置未生效 1.可能proxy_pass 未放置在最下面 2.或者 使用nginx -s stop 或 nginx -s quit 停止nginx，使用tasklist|findstr “nginx.exe”， 查看是否还有nginx进程，如果有，使用 taskkill /f /im nginx.exe 杀死所有nginx进程， 再次重启nginx ...
【运维】第03讲（下）：Nginx 负载均衡常见架构及问题解析
ihero的博客
07-16 573
我们了解后端服务获取IP的方式，第一种方式是由后端服务通过 4 层 TCP 协议获取源 IP 地址，你会发现，通过这种方式，后端服务只能获取 Nginx 的 IP 地址，而无法获取到 100.100.100.100 这个 IP 地址，原因在于 Nginx 做了一层反向代理，而反向代理修改了客户的源地址和源端口的包头，所以在后端服务，通过这种方式只能获取到 Nginx 的 IP，而无法获取到用户的 IP。ip_hash 就是基于用户 IP 来做 hash，一个用户的请求统一分发到一台机器上。
Nginx架构及配置详解
企业实战系列集 ●●● https://ximenjianxue.blog.youkuaiyun.com
09-10 5912
概述 Nginx采用C进行编写，是俄罗斯程序员开发的一款轻量级的可构建Web 服务器/反向代理服务器及电子邮件（IMAP/POP3）代理服务器的软件， Nginx服务器是一个高性能的HTTP和反向代理web服务器，同时也可提供了IMAP/POP3/SMTP服务。nginx常用作跑静态和做负载反向代理，动态php交给apache处理，因后者比较稳定，jsp交给tomcat、resin或jboss。n......
【笔记】nginx - 下：负载均衡、高可用（keepalived）、下载点、用户认证、集成lua
LawssssCat的博客
01-19 994
# 需求 主页菜单列表改为动态呈现方式 （不同用户登录，看到的菜单是不一样的！） # 实现 服务端设计 step01：设计 VO 对象 （ SysUserMenuVo ） @ 需要的资源：id、name、url --- 基于此对象，封装用户菜单信息(用户访问权限的菜单) public class SysUserMenuVo implements 序列化接口{ UID......
nginx 做proxy 不转发 http header问题解决
热门推荐
wx_mdq的专栏
08-28 2万+
使用nginx做负载均衡或http代理时，碰到http header不转发的问题。   配置里只有转发设置原始ip和host的             proxy_set_header Host $host;         proxy_set_header X-Real-IP $remote_addr;         proxy_set_header     X-Forwarde
nginx做代理不转发自定义http header问题
小白菜的专栏
03-09 7326
最近用nginx做转发代理遇到一件很奇怪的事情，自定义的header信息丢失了，为什么会出现这样的问题那？ 通过查阅资料发现，nginx确实存在这样的问题。nginx里是有关于相关的配置决定这块的，那就是说我们可以通过配置解决这块了？是的，没错。 原始的nginx配置不会转发host和IP等信息，对自定义的header信息不转发，具体如下：proxy_set_header Host host;
nginx反向代理proxy_set_header自定义header头无效
dalaoshu321的博客
09-15 795
原文地址：http://www.ttlsa.com/nginx/nginx-proxy_set_header/ 公司使用nginx作为负载均衡，有时候需要自定义header头发送给后端的真实服务器. 想过去应该是非常的简单的事情. 例子如下： 设置代理服务器ip头 proxy_set_header X-Forwarded-For $proxy_add_x_f...
nginx响应头添加不起作用问题
oYiNianChengMo的博客
05-29 858
nginx配置中可以通过nginx.conf配置响应头，在安全测试中经常会用到。但是在某些特殊场景下会添加失败。
解决 Nginx 配置未生效/没用/没效果，原因竟是 Windows 版本脏的重启？
Miozus Blog
10-07 7495
???? 1. 安装 Windows 版本（单机版，非虚拟机，选择 .zip 文件，解压可用） nginx: download官网下载地址 浏览器访问 localhost 得到 Welcome to nginx! If you see this page, the nginx web server is successfully installed and working. Further configuration is required. For online documentation an
nginx代理，自定义请求头遇到的坑
狮子头儿的博客
09-02 2105
问题现象： 前后端分离项目，后端为JAVA，自定义请求头header MY_TOKEN做鉴权，开发环境前端请求接口，运行正常。 部署至服务器，使用nginx做了代理，进行转发。此时奇怪的事情发生了，服务端取不到 自定义headerMY_TOKEN 的内容了 分析： 出现异常，无非是因为nginx做转发引起的。推测应该nginx转发没有携带请求头引起的，查找资料发现 句法： underscores_in_headerson|off; 默认： underscores...
nginx配置后不生效的问题
fengbin2005的专栏
12-28 825
----改成下面 要不然 通过curl http://xxx.i.sinotrans.com/test/index.html 报404。
自定义请求头（token等）后预检请求被服务器拒绝（报跨域）的解决方法
XD_NML的博客
11-22 2678
起因：由于在自定义请求头后请求会从简单请求转变为复杂请求，（详情可以查看阮一峰先生的博客）复杂请求会提前发送一个预检请求与服务器进行沟通，大概类似于（预检请求：“我可以访问吗？”=>服务器：“可以” =>真实请求）,这里有个坑，因为无论服务器是否允许请求，options请求（预检请求）的状态码反馈都是200ok，最开始没反应过来，服务器拒绝了options请求并且报跨域，但是options请求一直都是200ok，导致一直在看真实请求的问题出在哪还有后端是不是没有配置跨域。最简单的方法是看看op.
跨域为什么设置'Access-Control-Allow-Origin'头，流程是什么杨的
03-08
<think>好的，用户现在想了解跨域问题中设置'Access-Control-Allow-Origin'头的原因以及整个流程是怎么样的。首先，我需要回忆一下CORS（跨源资源共享）的基本原理。跨域问题主要是因为浏览器的同源策略，它阻止不同源的请求，比如不同域名、端口或协议。而设置这个响应头就是为了告诉浏览器该资源允许被指定的源访问。 接下来，用户可能对具体的流程不太清楚，需要详细解释。流程分为简单请求和非简单请求两种情况。简单请求如GET、POST等，直接发送请求，服务器返回相应的CORS头，浏览器检查是否允许。非简单请求比如PUT、DELETE或带有自定义头的请求，会先发送预检请求（OPTIONS），服务器响应允许的方法和头之后，浏览器才会发送实际请求。 然后，我需要考虑用户可能存在的疑问点。例如，为什么需要预检请求？这是因为非简单请求可能对服务器数据有更大影响，预检请求确保服务器明确允许这些操作，避免不必要的安全风险。另外，用户可能想知道如何具体配置服务器，尤其是Nginx或者后端框架中的设置方法，这时候需要给出示例配置，帮助他们实际操作。 还有，用户可能遇到常见的配置错误，比如忘记处理OPTIONS方法，或者没有正确设置其他相关的头如Access-Control-Allow-Methods和Access-Control-Allow-Headers。这时候需要提醒他们注意这些细节，并提供具体的解决方案。 最后，总结整个流程，强调服务器和浏览器之间的交互步骤，确保用户能够清晰地理解整个CORS的工作机制。同时，补充一些常见问题，比如为什么设置了*还是报错，可能是因为需要携带凭证（如cookies），这时候必须指定具体的源而不是通配符，或者需要设置Access-Control-Allow-Credentials头。</think>$\boxed{跨域原理与流程详解}$ 跨域问题的核心是浏览器的 **同源策略（Same-Origin Policy）** 限制。通过设置`Access-Control-Allow-Origin`响应头，服务端明确声明允许哪些外部域访问资源。以下是完整交互流程与技术细节： --- ### 一、跨域请求触发条件 当以下任意一项不同时触发跨域检测： - 协议（http/https） - 域名（主域/子域） - 端口号（8080/3000） **示例**： 从`http://a.com`请求`http://b.com/api` → 跨域 --- ### 二、CORS完整流程（分两类请求） #### 🔵 **1. 简单请求（Simple Request）** **条件**（同时满足）： - 方法为 GET / HEAD / POST - 仅含以下请求头： `Accept`, `Accept-Language`, `Content-Language`, `Content-Type` （其中`Content-Type`仅限：`text/plain`, `multipart/form-data`, `application/x-www-form-urlencoded`） **交互流程**： ```mermaid sequenceDiagram Browser->>Server: 直接发送实际请求（如GET） Server-->>Browser: 响应包含： Note right of Server: Access-Control-Allow-Origin: [指定域] 或 * Browser->>Browser: 检查响应头是否匹配当前域 alt 匹配 Browser-->>JS: 返回数据 else 不匹配 Browser-->>JS: 触发跨域错误 end ``` --- #### 🔴 **2. 预检请求（Preflight Request）** **触发条件**（任一）： - 使用 PUT / DELETE / PATCH 等方法 - 自定义请求头（如`X-Auth-Token`） - `Content-Type`为`application/json` **交互流程**： ```mermaid sequenceDiagram Browser->>Server: 发送OPTIONS预检请求 Note left of Browser: 包含： Origin: http://a.com Access-Control-Request-Method: PUT Access-Control-Request-Headers: X-Custom-Header Server-->>Browser: 响应策略声明： Note right of Server: Access-Control-Allow-Origin: http://a.com Access-Control-Allow-Methods: PUT Access-Control-Allow-Headers: X-Custom-Header Access-Control-Max-Age: 86400 Browser->>Browser: 验证预检响应 alt 验证通过 Browser->>Server: 发送实际PUT请求 Server-->>Browser: 返回真实数据（仍需包含CORS头） else 验证失败 Browser-->>JS: 终止后续请求 end ``` --- ### 三、关键响应头说明 | 响应头 | 作用 | 示例值 | |---------------------------------|--------------------------------------|----------------------------------| | `Access-Control-Allow-Origin` | 允许访问的源（必选） | `http://a.com` 或 `*` | | `Access-Control-Allow-Methods` | 允许的HTTP方法（预检响应需要） | `GET, POST, PUT` | | `Access-Control-Allow-Headers` | 允许的自定义请求头（预检响应需要） | `X-Custom-Header, Content-Type` | | `Access-Control-Expose-Headers` | 允许前端读取的响应头（非默认头需声明）| `X-Total-Count` | | `Access-Control-Max-Age` | 预检结果缓存时间（秒） | `86400` (24小时) | | `Access-Control-Allow-Credentials` | 是否允许发送Cookie（需与`Origin`显式配置配合） | `true` | --- ### 四、服务端配置示例 #### 🔧 Nginx配置 ```nginx location /api { # 基础CORS设置 add_header 'Access-Control-Allow-Origin' 'http://a.com'; add_header 'Access-Control-Allow-Methods' 'GET, POST, OPTIONS'; add_header 'Access-Control-Allow-Headers' 'DNT,User-Agent,X-Requested-With,Content-Type'; # 处理预检请求 if ($request_method = 'OPTIONS') { add_header 'Access-Control-Max-Age' 86400; add_header 'Content-Type' 'text/plain; charset=utf-8'; return 204; } } ``` #### 🔧 Node.js Express配置 ```javascript app.use((req, res, next) => { res.header('Access-Control-Allow-Origin', 'http://a.com'); res.header('Access-Control-Allow-Methods', 'GET, POST, PUT'); res.header('Access-Control-Allow-Headers', 'Content-Type, Authorization'); // 处理预检请求 if (req.method === 'OPTIONS') { res.header('Access-Control-Max-Age', '86400'); res.sendStatus(204); } else { next(); } }); ``` --- ### 五、常见错误场景 1. **通配符`*`失效**： 当请求携带Cookies等凭证时，`Access-Control-Allow-Origin`不能为`*`，必须明确指定域名，并设置： ```nginx add_header 'Access-Control-Allow-Credentials' 'true'; ``` 2. **未处理OPTIONS方法**： 若服务器未正确响应OPTIONS请求，浏览器将阻止后续实际请求。 3. **缓存污染**： 修改CORS策略后，需清理浏览器缓存或设置`Access-Control-Max-Age`为0。 --- $\boxed{核心总结}$ - **安全基石**：CORS是浏览器强制执行的策略，与服务端是否返回200状态码无关 - **流程本质**：通过预检请求协商安全策略，再执行实际请求 - **最佳实践**：生产环境应严格限制`Access-Control-Allow-Origin`为具体域名，避免使用`*`
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值