nginx默认透传cookie，无需配置；误用proxy_set_header cookie会清空关键信息；需改写时用map提取字段；cookie有效性还依赖domain、path、secure属性，应配合proxy_cookie_domain等指令修正。
默认情况下，Nginx 就会把客户端原始的 Cookie 请求头原样转发给后端，不需要额外配置。真正出问题的，往往是误操作主动覆盖了它。
别手动清空或覆盖 Cookie 头
常见错误是写了类似这样的配置：
FastAPI Flask Proxy
下载
FastAPI + Flask 混合部署最佳实践，解决路由定义、API 代理等常见问题，适用于同时运行 FastAPI API 与 Flask 前端的场景。
-
proxy_set_header Cookie "";—— 这会彻底清空 Cookie，导致后端收不到 sessionid、token 等关键信息 -
proxy_set_header Cookie $http_cookie;—— 表面看是透传，但若客户端请求本身没带 Cookie（比如首次访问），$http_cookie 为空，结果等效于清空
需要透传就保持默认，需要改写再动手
绝大多数场景下，什么都不配就是最安全的做法。Nginx 默认行为就是继承并转发原始 Cookie。
- 如果后端依赖特定 Cookie（如
auth_token或user_id），且需剥离其他字段，应配合map指令提取后再透传 - 例如只传 user_id：
map $http_cookie $user_id {
~*user_id=([^;]+) $1;
default "";
}
proxy_set_header X-User-ID $user_id;
注意 Host 和协议一致性，否则 Cookie 可能被浏览器拒绝
Cookie 能否正确发送，不仅取决于 Nginx 是否转发，还和 Domain、Path、Secure 属性有关：
- 若用户用
https://app.example.com访问，而后端返回的Set-Cookie中含Domain=backend.local，浏览器会直接丢弃 - 此时要改的是响应头里的 Cookie 属性，不是请求头 —— 应用
proxy_cookie_domain和proxy_cookie_path指令重写 - 确保
proxy_set_header X-Forwarded-Proto $scheme;已配置，让后端知道原始是 HTTPS，从而正确设置Secure标志
