上传附件遇到 413，应该从哪一层排查

413 Request Entity Too Large 不是附件损坏，也不是保险库密码错误。它表示请求在到达处理逻辑之前，已经被某一层按大小拒绝。自部署通常同时存在公网反向代理、xypass Gateway 和应用自身限制，需要先判断响应来自哪里。

先记录请求路径和文件大小

在浏览器开发者工具中查看失败请求。附件分块接口、同步推送和支持工单附件虽然都位于 /api/，但使用不同的应用限制。记录请求路径、状态码、响应头、文件原始大小和发生时间，不要把附件正文或认证 Header 发到工单。

如果 xypass Web 和 API 日志中完全没有这次请求，413 多半来自 Nginx Proxy Manager、Cloudflare 或其他公网入口。调整实际终止 HTTPS 的 Proxy Host，请求体上限至少要容纳 xypass 支持的有效载荷。

只改容器内 Gateway 不会覆盖外层代理的更小限制；同样，只改外层代理也不能绕过应用自己的安全上限。

当前生产 Gateway 对 /api/pass/ 允许最多 16 MiB，请求的其他路径默认保持更小限制。xypass 单个保险库附件的明文上限是 10 MiB，加密、编码和请求结构会产生额外开销，因此代理上限不能简单设置成 10 MiB。

如果你修改过 gateway.conf，确认运行中的容器确实加载了新配置，并检查请求是否走到了预期的 /api/pass/ 路由。重建 Web/Gateway 后再测试，不需要为这类配置变更重启 PostgreSQL。

应用仍会拒绝超过产品上限的文件，扩大代理限制不会让超大附件变得可用，反而会增加内存、带宽和拒绝服务风险。先用一个很小的测试文件验证链路，再逐步测试接近上限的文件。

修复完成后，既要验证附件上传，也要验证普通同步推送。最终配置应满足当前产品限制，并由外到内逐层收紧，而不是把所有代理都设成“无限制”。