根本原因是Nginx默认未透传请求头（如Authorization、X-Forwarded-For）、丢弃含下划线的头（如api_key_id），且Hyperf未配置可信代理；需配置proxy_set_header透传关键头、underscores_in_headers on启用下划线支持，并在Hyperf中设置trusted_proxies。
Hyperf 应用在 Nginx 反向代理后收不到某些请求头（如 Authorization、X-Forwarded-For、带下划线的自定义头如 api_key_id），根本原因不是 Nginx “删掉了”头，而是默认未透传或主动忽略。修复需从三方面入手：基础转发配置、下划线支持、Hyperf 侧适配。
必须添加的基础 header 转发
Hyperf 默认依赖 Host、X-Forwarded-For、X-Forwarded-Proto 等头做协议判断、IP 获取和跳转生成。若缺失，会导致登录重定向错误、HTTPS 混合内容、日志 IP 显示为 127.0.0.1 等问题。
-
Host：用
proxy_set_header Host $host;（非$proxy_host），确保 Hyperf 知道用户访问的是哪个域名 -
真实客户端 IP：同时设置
proxy_set_header X-Real-IP $remote_addr;和proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; -
协议识别：加
proxy_set_header X-Forwarded-Proto $scheme;，否则 Hyperf 可能误判 HTTPS 请求为 HTTP，生成http://跳转链接 -
强制开启头传递：加上
proxy_pass_request_headers on;（虽是默认值，但显式声明更稳妥）
处理带下划线的请求头（如 api_key_id、gray_sign）
Hyperf 接口常通过 api_key_id、user_token 等含下划线的 header 做鉴权。Nginx 默认丢弃所有含 _ 的 header 字段——这是最隐蔽也最常见的丢失原因。
- 在
http{}块顶层（不能放在 location 或 server 内）添加：underscores_in_headers on; - 重启 Nginx 生效（仅 reload 不生效，需
nginx -s reload或 systemctl restart） - 若仍需显式转发某一个下划线头（如兼容旧版本或调试），可补充：
proxy_set_header Api-Key-Id $http_api_key_id;（注意变量名自动转小写+中划线）
Hyperf 侧需启用信任代理配置
即使 Nginx 正确转发了 X-Forwarded-For 和 X-Forwarded-Proto，Hyperf 默认不信任这些头，会直接读取原始连接信息，导致 IP 和协议识别失效。
- 修改
config/autoload/server.php中的settings： - 添加
'trusted_proxies' => ['127.0.0.1', '10.0.0.0/8', '172.16.0.0/12', '192.168.0.0/16'],（填 Nginx 所在服务器真实 IP 或网段） - 确保
'enable_coroutine' => true下的 Swoole 配置已启用http协议解析 - 验证方式：在控制器中打印
$request->server['remote_addr']和$request->getHeaders()，确认是否拿到x-forwarded-for和真实authorization
快速验证是否修复成功
别只看 Nginx 配置有没有加，要验证后端实际收到什么：
- 用 curl 发起带自定义头的请求：
curl -H "Api-Key-Id: abc123" -H "Authorization: Bearer xyz" https://your-domain.com/api/test - 在 Hyperf 控制器中打印：
var_dump($request->getHeaders());，检查api_key_id、authorization是否存在且值正确 - 查看 Hyperf 日志中的 client IP 是否为真实用户 IP，而非 127.0.0.1
- 若使用 Hyperf 的 JWT 或 Auth 组件，测试登录后跳转 URL 是否为
https://开头，而非http://
