Nginx 代理 Node 服务时头信息与日志怎么拆

2021年9月20日 · 阅读需 2 分钟

全栈开发者

Nginx 给 Node 服务做反向代理是很常见的组合，但很多项目把配置写到“能转发请求”就停了。真正上线跑一段时间后，问题通常出在另一层：Node 应用到底有没有拿到正确的客户端信息，日志又能不能支撑定位问题。

这两件事如果前期没定清楚，后面查一次线上问题就会特别痛苦。

代理头信息不是可有可无

像 Host、X-Forwarded-For、X-Forwarded-Proto 这些头，直接影响 Node 应用怎么看待原始请求。如果 HTTPS 在 Nginx 终止，而应用层又需要知道原始协议，就必须把相关头显式传下去。

否则回调地址、重定向、审计日志都可能出现偏差。

很多框架默认并不知道自己身后还有一层 Nginx，所以即使头信息传了，应用层也未必会正确使用。这里最容易出问题的，是生成绝对地址和判断安全连接时的逻辑。

反向代理配置和应用信任设置，本来就应该成对检查。

后台项目常见的访问类型至少有两类：

如果全都混在一份 access log 里，后面分析慢接口、错误接口和刷资源请求时会很难看。按 location 或 upstream 拆日志，维护成本并不高，但收益非常直接。

把日志级别一口气开到很高，并不一定更安全。更现实的方式是按环境控制，线上保持足够排障的信息量，预发或问题复现场景再适度放大。

日志的目标是帮助定位，而不是制造更多噪音。

Nginx 代理 Node 服务时，最值钱的不是那几行 proxy_pass，而是头信息有没有传对、日志有没有拆清。只要这两层收好，2021 年常见的线上排障场景会轻松很多。