刚接入腾讯云EO（边缘加速）就碰上504 Gateway Timeout，这感觉我懂。504的本质是“等待超时”，问题通常不在EO本身，而在请求链路的某个环节“太慢了”。别慌，按下面三层结构排查，大部分情况都能快速定位。 第一层：检查源站健康状况（最快排除） 首先，你需要绕过EO，直接测试源站。 直连源站：使用服务器IP或未经过EO加速的域名，用curl或浏览器访问出现504的相同页面。如果同样慢或超时，那问题很明显出在你的源站服务器上（如CPU满载、数据库死锁、应用崩溃）。 检查基础资源：登录云服务器控制台，查看出现504时段内的CPU、内存、带宽使用率监控图。流量激增或资源耗尽是最常见原因。 如果直连源站很快，但通过EO就504，那么问题大概率出在“EO ↔ 源站”的通路上。 第二层：分析EO配置与日志（核心步骤） 这是排查腾讯云EO 504错误的关键环节。 确认“回源超时”设置：登录EO控制台，检查你配置的回源超时时间。默认值可能不适合你的应用。如果源站处理某个复杂请求需要25秒，而你的回源超时设置是10秒，EO就会主动断开并返回504。适当调增这个时间（如设为30秒） 可能是立竿见影的解法。 查看实时日志：EO提供访问日志和回源日志。重点筛选出状态码为504的日志条目，查看 upstream_response_time（上游响应时间）字段。如果这个时间接近或等于你的回源超时设置，就验证了是回源超时问题。同时，注意日志中的 upstream_addr（回源地址），确认EO回源到了正确的、健康的服务器IP。 第三层：排查网络链路与源站配置 如果日志显示源站响应时间确实很长，但直连又不慢，矛盾就指向了网络或特定配置。 EO到源站的网络质量：从你的源站服务器，对EO的回源节点（可以从日志中找到IP）执行MTR或长ping测试，检查是否存在跨运营商、跨地域的网络延迟或丢包。有时，源站防火墙对特定回源IP段的限速策略也会导致此问题。 源站特定配置：检查源站Web服务器（如Nginx、Apache）的超时配置（如 proxy_read_timeout、 fastcgi_read_timeout）。确保这些配置值大于EO的回源超时时间，否则请求会在源站内部被中断。 动态内容瓶颈：确认504是否只发生在特定动态页面（如涉及复杂查询、调用外部API）。这可能是因为源站应用处理这些请求本身过慢，需要优化程序或数据库。 给您的行动路线： 立即操作：登录EO控制台，检查并调整回源超时时间为更合理的值（如30秒）。 同步分析：下载并分析过去一小时的EO回源日志，锁定504错误的请求模式和上游响应时间。 深度检查：按照上述三层结构，从源站健康、网络链路到应用代码，逐一对比排查。 记住，EO作为网关，其 “网关超时” 是一个结果，而非原因。你的核心任务是找到并解决从EO回源到您源站服务器这个链条上的性能瓶颈。多数情况下，调整超时配置或优化源站性能，问题即可解决。

EO接入后的504，基本可以锁定是 “请求在某个环节超时等待” 了。别慌，按照这个顺序排查，大部分情况能在三分钟内定位方向。 第一步：立刻检查“回源头”——优先级最高 504意味着EO节点在规定时间内（默认约60秒）没收到源站响应。这是最直接的线索。 HTTPS回源问题：这是新手高频雷区。EO提供了HTTPS卸载能力，但你的源站是否配置正确？ 检查项：在EO控制台，确认回源协议。如果你在EO上开启了HTTPS加速并选择“HTTP回源”，但源站却关闭了80端口或强制跳转HTTPS，连接立刻失败。 快速验证：在服务器上，用 curl -I http://你的源站IP或域名 测试HTTP回源是否通畅。 源站性能瓶颈： 排查：登录源站服务器，检查接入EO后的监控。重点看CPU、内存、网络连接数。EO的并发能力很强，可能瞬间把请求压到源站，如果源站本身处理慢（如数据库查询未优化），就会超时。 关联线索：如果只有动态请求（如API、登录页）报504，而静态资源正常，问题几乎肯定出在源站应用程序或后端服务上。 第二步：审视“EO中间件”——规则与缓存 排除了源站问题，就要看EO自身的配置是否成了瓶颈。 WAF规则拦截或延迟： 检查项：进入EO的Web应用防火墙（WAF） 日志。查看是否有规则在“观察”或“拦截”模式下的请求。某些复杂的WAF规则（如CC防护、精准防护）在深度检测时可能引入延迟，或误将正常请求转入挑战流程，导致整体超时。 行动：临时将疑似影响的域名或IP加入WAF白名单，观察是否恢复。 缓存配置引发雪崩： 场景：如果大量请求的缓存配置为“忽略参数”或“缓存键”设置不合理，可能导致缓存未命中，所有请求穿透回源。特别是当源站响应慢时，回源连接池迅速被占满，新请求排队超时。 排查：检查EO缓存命中率。如果命中率骤降且与504时间点吻合，需检查是否为热门URL设置了“不缓存”或缓存时间极短。 第三步：网络与高级特性 前两步能解决90%的问题。如果还有，需深挖： EO特性配置：检查是否开启了“智能压缩”、“Brotli压缩”等高级功能。某些老旧或不兼容的源站应用，在处理被EO预处理过的请求时可能出错或变慢。 DNS与网络链路：虽然不常见，但需确认EO回源DNS解析的IP是否正确，以及到源站IP的网络是否存在波动或防火墙拦截（检查安全组/ACL规则）。 给你的行动清单： 立即：查源站监控与日志，验证回源协议与端口。 随后：查看EO的WAF拦截日志与缓存命中率图表。 最后：复核近期更改的EO配置，特别是回源、缓存、WAF相关设置。 记住，EO是加速器，不是源站。504的本质是回源链路的超时。从源站承受力倒查，再到EO规则，这个顺序能帮你最快止血。

504错误本质是“超时”。接入EO后，问题通常出现在新的链路上。别急着回滚，按这个顺序排查，大部分能快速定位。 第一步：检查EO基础配置（最快验证） 先排除配置失误： 回源超时设置：登录EO控制台，检查“回源配置”中的连接超时和接收超时时间。默认值可能对你的源站偏短。建议先临时调大（如设为30秒），测试是否缓解。 健康检查：确认源站健康检查配置正确。若EO误判源站不健康，会将流量切到不存在的备份节点，导致504。 这一步5分钟就能试完，很多初级问题出在这里。 第二步：聚焦“全链路超时”排查 504意味着在某个环节（EO节点 -> 回源网络 -> 源站服务器）请求超时。你需要分段定位： EO边缘节点耗时：在EO控制台或通过日志，查看命中缓存的请求响应是否正常。如果缓存命中率低或动态请求直接回源，进入下一步。 回源网络质量：EO到你的源站可能跨运营商。通过EO的链路追踪工具或让运维在源站抓包，分析TCP建立连接、SSL握手、首包时间是否异常。网络抖动或跨网延迟高是常见原因。 源站处理能力（重点怀疑）：这是最常见瓶颈。接入EO后，所有流量集中从少数EO回源节点打过来，可能改变了源站的连接模式，暴露了源站容量不足或架构瓶颈。 第三步：诊断源站瓶颈与进行“全链路压测” 接入EO可能改变了流量形态，你需要评估： 并发连接数：EO回源连接池可能用尽，导致新请求排队超时。检查源站Web服务器（如Nginx、Apache）的worker_connections、max_clients等参数，以及数据库连接池。 单请求处理性能：某些动态页面（如含复杂查询、API调用）本身处理慢。接入EO前，可能因客户端直接访问且浏览器有超时重试，感知不强；现在经过EO代理，其默认超时时间更严格，问题被放大。 如何进行全链路压测排查504：不要只压测源站。使用压测工具模拟EO回源节点的IP和行为，对关键动态页面进行压测，观察在多少并发下开始出现超时。这能真实反映EO接入后的整体架构性能。 第四步：利用EO功能进行优化与兜底 排查后，针对性解决： 源站扩容建议：如果确认是源站容量瓶颈，考虑水平扩容应用服务器，或升级数据库。这是根本解决之道。 调整EO策略：对于慢速动态内容，适当调大EO回源超时时间（但需评估用户体验）。对于可缓存的页面或静态元素，检查缓存规则是否可优化，提高命中率，减轻回源压力。 配置腾讯云EO故障转移：在“回源配置”中设置主备源站。当主源站超时或不可达，EO能自动切换到备用源，提升可用性，为修复争取时间。 静态资源彻底分离：确保所有静态资源（图片、JS、CSS）通过EO加速且缓存命中率高，避免无谓的回源消耗源站容量。 给你的行动路线图： 立即：检查EO控制台的回源超时配置与健康检查状态。 随后：分析EO日志，定位是动态请求还是缓存未命中导致。 深入：对源站进行针对性监控（连接数、CPU、慢查询）和从EO回源节点发起的全链路压测。 长期：根据压测结果制定源站扩容或架构优化方案，并配置好故障转移策略。 记住，接入EO相当于引入了一个新的观察点，它往往不是问题的制造者，而是将你源站或架构的既有瓶颈更清晰地暴露出来。