proxy_cookie_path必须在每个server块的location内单独配置，不可置于http顶层；不同虚拟主机间完全隔离，需按后端Cookie Path与前端路径映射关系分别设置，如a.example.com用proxy_cookie_path / /app1/，b.example.com用proxy_cookie_path /v1/ /app2/。
在多虚拟主机（multi-server）环境下，proxy_cookie_path 不能直接写在 http 块顶层——它必须放在具体的 location 块内，且只对当前 server 和该 location 下的代理响应生效。不同虚拟主机之间完全隔离，彼此的 Cookie 路径映射互不影响。
每个 server 块需独立配置 proxy_cookie_path
虚拟主机本质是多个独立的 server 块（按域名、IP 或端口区分），它们共享 http 全局配置，但所有代理相关指令（包括 proxy_cookie_path）都需按需下沉到各自内部的 location 中：
- 不要在
http或upstream块里写proxy_cookie_path，无效 - 每个
server中，只要用了proxy_pass，且后端返回的 CookiePath与前端访问路径不一致，就必须在对应location里配proxy_cookie_path - 例如：
server_name a.example.com和server_name b.example.com是两个虚拟主机，它们各自的/api/路径可能代理不同后端，也需分别设置路径映射
典型多虚拟主机配置示例
假设两个域名共用一台 Nginx，分别代理不同后端服务，且都挂载在子路径下：
server {
listen 443 ssl;
server_name a.example.com;
<pre class="brush:php;toolbar:false;">location /app1/ {
proxy_pass https://backend-a/;
proxy_cookie_path / /app1/; # 后端设 Path=/ → 改为 Path=/app1/
}}
FastAPI Flask Proxy
下载
FastAPI + Flask 混合部署最佳实践，解决路由定义、API 代理等常见问题，适用于同时运行 FastAPI API 与 Flask 前端的场景。
server { listen 443 ssl; server_name b.example.com;
location /app2/ {
proxy_pass https://backend-b/v1/;
proxy_cookie_path /v1/ /app2/; # 后端设 Path=/v1/ → 改为 Path=/app2/
}}
注意：两个 server 中的 proxy_cookie_path 规则互不干扰，各自处理自己域名下的请求和响应。
避免跨 server 的 Cookie 泄露风险
不同虚拟主机通常对应不同业务或租户，Cookie 的 Path 和 Domain 必须严格隔离：
-
proxy_cookie_path只改Path，不碰Domain；若后端设置了Domain=backend.local，还需配合proxy_cookie_domain backend.local a.example.com;（在对应server的location内） - 切勿用全局正则（如
proxy_cookie_path ~^/.*$ /;）覆盖所有 server —— 它只在当前 location 生效，且可能误匹配、破坏原有路径语义 - 若某虚拟主机需支持多级子路径（如
/admin/和/api/），应在各自location中分别配置，不可复用同一规则
验证是否生效
部署后，逐个访问各虚拟主机对应路径，通过浏览器开发者工具的 Application → Cookies 查看实际存储的 Path 值，或用 curl -I 检查响应头中的 Set-Cookie：
- 访问
https://a.example.com/app1/login→ 应看到Set-Cookie: ... Path=/app1/ - 访问
https://b.example.com/app2/user→ 应看到Set-Cookie: ... Path=/app2/ - 若仍显示
Path=/或Path=/v1/，检查 location 是否精确匹配、指令是否拼写正确（如不是proxy_cookie_path）、后端是否真返回了该 Cookie
