504 gateway timeout 是网关因上游服务响应超时而返回的错误，需同步调高 nginx/apisix 的 proxy_read_timeout 等参数，并确保后端 tomcat、dns、xml 解析及网络链路无阻塞。
504 Gateway Timeout 就是网关“等不及”后端响应，直接向你返回失败 —— 它本身不是你的代码错，而是中间那层（Nginx / APISIX / CDN / API 网关）在转发 XML 上传请求时，上游服务没在规定时间内给回包。
XML 上传接口卡在 504？先盯住这三处超时参数
XML 文件（尤其带附件、签名或嵌套结构的）上传常触发长连接、大体积分块、校验耗时等问题。Nginx 默认 proxy_read_timeout 是 60 秒，但一个含数字签名 + XSD 校验 + 数据库写入的 XML 接口，很容易超过这个阈值。
-
proxy_connect_timeout：Nginx 连后端（如 Spring Boot 应用）TCP 握手超时，一般设为75s足够 -
proxy_send_timeout：Nginx 向后端发完全部 XML 数据后，等待后端开始处理的间隔，建议180s（防大文件分片慢） -
proxy_read_timeout：最关键的项 —— Nginx 等待后端完整响应的时间，XML 处理链路长，必须调高，例如：proxy_read_timeout 300s;
⚠️ 容易踩的坑：只改了 proxy_read_timeout，却忘了后端 Tomcat 的 connectionTimeout 或 Spring Boot 的 server.tomcat.connection-timeout（默认 20 秒），结果 Nginx 没超时，Tomcat 先断连，日志里反而报 502 或连接重置。
APISIX 或云网关上传 XML 时 504？检查 route 和 upstream 的 timeout 配置
APISIX 不像 Nginx 那样全局生效，它的超时控制分散在 route 和 upstream 两级。如果你的 XML 接口走的是独立路由（比如 /api/v1/submit-xml），就必须显式配置：
- 在
route中设置timeout: { connect: 60, send: 120, read: 300 } - 在
upstream中确认keepalive_timeout≥read值，否则连接池提前回收，导致重复建连+超时叠加 - 若启用了插件如
limit-count或request-validation，它们也会消耗处理时间 —— 查看 APISIX 日志中latency字段，确认是否插件执行占了大头
? 实操建议：临时加个 echo 插件打点，在 XML 解析前/后各记录一次时间戳，快速定位是解析慢、校验慢，还是 DB 写入慢。
