本文篇幅虽简短，但却是我本周最大的收获，也希望能帮到看到本文的同学，少踩一个坑。
NodeJS常见的部署方式是通过NGINX作为负载均衡的代理转发。
前端自定义了一个请求头user_id来标识每一个用户的请求，调试的时候通过ip+port的方式访问万事大吉，当配置了nginx作为代理转发后，一切开始变得不美好了。在Node层拿不到用户的唯一标识user_id了。
我一开始以为是Node函数调用的问题，没有正确地拿到请求头，
再度怀疑是nginx没有将请求头代理传给到Node服务。
那么，我自定义的请求头到底跑到哪里去了？
不走nginx代理是OK的，那么显然不能归咎于Node。
到底是谁制造了这一起失踪案呢？
我再一次陷入了沉思。。。
.
.
.
.
.
.
.
.
.
.
.
.
.
.
突然，智慧之神降临了，Google先知告诉我，NGINX自己把请求头藏起来了。
原来nginx代理默认会把header中参数的 "_" 下划线去掉，所以后端Node服务就获取不到带"_"线的参数名。
元芳，你怎么看呢？
真相就在这里，客户请求的参数user_id包含了"_"，nginx代理会默认忽略。
真的是无巧不成书，一脚踏入了这个坑中。
如果将自定义的请求头user_id改成userId，那就不会掉进这个坑。
如果非要使用自定义请求头user_id怎么办呢？
修改nginx中http的配置即可，underscores_in_headers由off设置为on。
underscores_in_headers on;
#该属性默认为off，表示如果header name中包含下划线，则忽略掉。| Syntax: | underscores_in_headers |
|---|---|
| Default: | |
| Context: | http, server |
Enables or disables the use of underscores in client request header fields. When the use of underscores is disabled, request header fields whose names contain underscores are marked as invalid and become subject to the ignore_invalid_headers directive.
NGINX文档参见：http://nginx.org/en/docs/http/ngx_http_core_module.html#underscores_in_headers
本文作者： 黑马大前端 cuitianze
