504网关超时本质是nginx转发请求后未在规定时间内收到上游响应，排查须先确认location路径匹配是否精准、proxy_pass指向是否为健康可检服务、超时参数是否在正确作用域显式配置且与业务实际耗时匹配。
504网关超时本质是Nginx在转发请求后，没能在规定时间内收到上游响应。排查要从配置结构本身入手，而不是一上来就调大超时时间——结构错，参数再合理也白搭。
检查location块是否精准匹配请求路径
Nginx按最长前缀匹配location，若路径配置模糊（比如用/兜底但没加^~或=），可能导致请求被错误路由到无意义的代理块，甚至进到默认静态服务逻辑里空转，最终触发超时。
- 确认表单提交的
action="/submit"是否被明确的location /submit { ... }捕获，而非被location / { proxy_pass http://...; }泛匹配 - 避免多个location重叠定义，尤其注意正则location（
~或~*）优先级高于普通前缀匹配，可能意外劫持请求 - 使用
nginx -T命令输出完整生效配置，人工核对目标请求路径实际落入哪个块
验证proxy_pass指向的是可健康检查的服务入口
proxy_pass不能直接写后端应用监听的原始端口（如http://10.0.2.10:3000），而应指向具备负载分发与健康检查能力的中间层，比如Internal ALB的DNS+80端口或K8s Service ClusterIP。
Pandas 配置文件报告生成器
下载
使用ydata-profiling（前身为pandas-profiling）生成全面的数据质量报告，包含相关性分析、缺失值模式和基数检测。导出交互式HTML仪表板和JSON摘要。
- 若指向EC2私有IP+应用端口，需确保安全组允许Web层IP访问该端口，且VPC路由可达；更稳妥做法是走ALB或NLB
- 检查ALB目标组：注册实例状态必须为
healthy，健康检查路径（如/health）能返回200，端口设置与后端应用一致（如3000） - proxy_pass值中不要带尾部斜杠（
http://xxx/），否则会截断location路径，导致上游收到错误URI
确认超时参数作用域和数值是否合理
timeout参数必须放在真正起作用的配置层级：全局http块设默认值，server或location块可覆盖。只改http块却在location里另写一个不带timeout的proxy_pass，新值不会生效。
-
proxy_connect_timeout：建议5–10秒，反映建立TCP连接的预期耗时 -
proxy_send_timeout：建议30秒，控制Nginx向上游发送完整请求体的时间上限 -
proxy_read_timeout：业务强相关，如含文件上传或复杂查询，可设为120–300秒；但应先确认后端是否真需要这么久 - 三个参数都需显式声明，避免依赖60秒默认值；且必须与
proxy_pass在同一location内
排除请求体处理阶段的隐性阻塞
504常被误判为“后端慢”，其实Nginx自身接收请求体就可能卡住——尤其是大文件上传、长Cookie或JSON数据体未及时刷入缓冲区时。
- 检查
client_max_body_size是否足够（如上传100MB文件需设100m），过小会返回413，但某些客户端重试逻辑可能引发后续504 -
client_body_buffer_size建议设为128k–512k，太小会导致频繁写临时文件，IO延迟升高 -
large_client_header_buffers至少设为4 64k，防复杂认证头或长Referer导致解析卡顿 - 这些参数通常放在
http或server块，不随location变化，容易被忽略
