多个前端项目部署在同一域名时，静态资源路径易冲突。解决方法：构建阶段为各项目设置独立的 publicPath 或 base（如 Vite 的 base: '/shop/'），使资源请求带上前缀；部署层再按 URL 前缀转发。Nginx 可使用 location + alias + try_files 将 /shop/、/user/、/report/ 等分别映射到对应前端目录，并配置默认跳转；Kubernetes Ingress 也可通过 path 区分后端服务，并能用 server-snippet 将 API 前缀重写转发到 Java 服务。这样可避免资源互相覆盖，实现多项目同域共存。

项目因仓促上线未做性能优化，静态资源加载缓慢。后期开启Gzip后，发现经`proxy_pass`反向代理的响应头中未出现`content-encoding: gzip`，而直接访问域名却正常。排查确认：Nginx与后端upstream默认使用HTTP/1.0协议通信，而Gzip压缩默认仅对HTTP/1.1及以上请求生效，导致代理链路中压缩失效。解决方案是在Nginx配置中增加`gzip_http_version 1.0;`，使HTTP/1.0及以上版本均启用压缩。配置生效后，静态资源由每个约300KB降至约70KB，显著提升加载速度。此案例提示，在使用反向代理时需关注HTTP协议版本对Gzip的影响。

文章针对后端通过WebClient转发text/event-stream流时，前端出现多个事件粘连堆叠、JSON被截断及乱码的问题，定位根因在于Nginx默认启用的代理缓冲与缓存机制。该机制会合并分块数据，破坏SSE流式响应的独立性与完整性。解决方案是关闭Nginx的proxy_buffering和proxy_cache，并设置响应头X-Accel-Buffering为no，使后端数据实时直传客户端。配置后每个流事件作为独立完整JSON返回，不再粘连、截断或解析出错。读者可据此处理类似SSE代理场景中的数据完整性故障，保障流式接口的实时性与正确性。