回源排障指南

CDN 节点作为网关无法从源站获得有效响应时会返回 502（Bad Gateway）。回源链路中以下任一环节失败都可能返回 502：

• 源站不支持 HTTPS（仅监听 80 端口）但 CDN 配置了 HTTPS 回源；

• 回源端口与源站实际监听端口不一致；

• 源站依赖 SNI 选择证书但 CDN 未携带或携带了错误的 SNI；

• 源站 SSL 证书过期、无效或与域名不匹配；

• 源站使用自签名证书或内部 CA 签发的证书，回源 TLS 校验失败。

排查步骤：

• 检查源站是否支持当前回源协议：执行 curl -Iv https://源站域名 直接验证源站。若连接被拒绝或超时，说明源站不支持 HTTPS，请将回源协议改为 HTTP；若源站支持 HTTPS 且证书有效，可选择 HTTPS 回源或协议跟随。

• 检查回源端口是否与源站监听端口一致：默认 HTTPS 回源端口为 443、HTTP 回源端口为 80。如果源站使用自定义端口（范围 1~65535），请在回源协议配置中填写对应端口。

• 检查回源 SNI 配置：当源站同一 IP 托管多个 HTTPS 站点时，源站依赖 TLS 握手中的 SNI（Server Name Indication）字段来选择对应的 SSL 证书。如果 CDN 回源未携带 SNI 或 SNI 值错误，源站无法匹配正确证书，TLS 握手失败，返回 502。

  解决步骤：登录 CDN 控制台 → 域名管理 → 选择目标域名 → 回源配置 → 开启回源 SNI，填写源站实际提供服务的域名（通常与源站证书的 Common Name 一致）。同时将回源 HOST 设置为源站域名。

  回源时 CDN 会校验 SNI 与源站证书 Common Name 的一致性，若两者确实无法保持一致（如源站使用统一接入层证书），可将证书的 Common Name 加入Common Name白名单。

  说明

  回源 SNI 用于 TLS 握手阶段选择证书，回源 HOST 用于 HTTP 层的虚拟主机路由，两者作用不同，但通常设置为同一个源站域名。

• 检查源站 SSL 证书有效性：确认证书未过期、未被吊销，且证书中的域名包含源站域名。可执行 curl -Iv https://源站域名 2>&1 | grep -E "expire|subject|issuer" 查看证书的有效期、颁发者和绑定域名。证书过期或与域名不匹配时请更新源站证书；若源站使用自签名证书或内部 CA 签发的证书，请更换为公有可信 CA 签发的证书，或将回源协议改为 HTTP。

解决方法：根据源站实际情况修改回源协议：源站只支持 HTTP → 选择 HTTP（端口默认 80）；源站支持 HTTPS 且证书有效 → 选择 HTTPS（端口 443 或自定义）；源站两者均支持且证书维护良好 → 可选择协议跟随。详细操作请参见配置回源协议。

回源协议为“跟随”时返回 502 如何排查？

回源协议设置为"跟随"时，CDN 跟随客户端的请求协议回源：客户端使用 HTTP 访问，CDN 以 HTTP 协议回源；客户端使用 HTTPS 访问，CDN 以 HTTPS 协议回源。如果客户端使用 HTTPS 访问而源站不支持 HTTPS，TLS 握手失败，回源请求失败。此问题与"回源返回 502 如何排查"同因，可按同一排查步骤诊断。

解决方案：

• 方式一：将回源协议从"跟随"改为"HTTP"，CDN 始终以 HTTP 协议回源。

• 方式二：为源站配置 SSL 证书，确保源站支持 HTTPS 访问。详细说明请参见配置回源协议。

504 错误（Gateway Timeout）表示 CDN 节点在回源时无法在指定时间内从源站获取响应。

常见原因包括：

• 源站响应慢或服务不可用。

• 回源请求被中间网络设备或防火墙丢包（SYN 包被丢弃时表现为连接超时）。

• 回源协议、端口配置错误导致连接无法建立（此时通常表现为 502，但若防火墙静默丢弃而非主动拒绝也可能表现为 504）。

• 回源读取超时时间设置过短，不能满足源站实际响应耗时。

回源超时分为两个阶段，对应不同的排查方向：

• 连接阶段超时：CDN 节点与源站建立 TCP 连接的超时时间为 10 秒。这一阶段超时通常说明源站未监听回源端口、防火墙或安全组丢弃了 CDN 回源 IP 的 SYN 包，或网络链路存在严重丢包。

• 读取阶段超时：连接已建立，但源站在回源读超时时间（默认 30 秒）内未返回完整响应。这一阶段超时通常说明源站处理慢，例如数据库慢查询、后端应用阻塞、源站负载过高。

排查步骤：

1. 检查源站是否可正常访问：直接通过 curl -I http(s)://源站域名 或浏览器访问源站，确认源站响应时间和状态码。如果源站本身响应慢或无法访问，需优先修复源站性能或可用性问题。

2. 定位耗时集中在哪个阶段：执行 ：

   curl -o /dev/null -s -w "time_connect:%{time_connect} time_starttransfer:%{time_starttransfer} time_total:%{time_total}\n" http(s)://源站域名/资源路径

   其中 time_connect 为 TCP 建连耗时，time_starttransfer 为收到首字节的耗时，time_total 为总耗时。

   • 若 time_connect 就已明显偏大，按连接阶段排查网络与防火墙；

   • 若 time_starttransfer 远大于 time_connect，说明源站业务处理慢，需优化源站；

   • 若 time_total 远大于 time_starttransfer，说明响应体过大或源站出带宽不足。

3. 检查回源协议和端口配置：确认 CDN 配置的回源协议、端口与源站实际监听一致。如果回源端口错误或源站未监听该端口，CDN 会在超时后返回 504。

4. 检查源站防火墙或安全组：如果源站对 CDN 回源 IP 段做了限流或拦截，可能导致部分请求超时。尤其是静默丢弃 SYN 包的策略，会直接表现为连接阶段超时。请将 CDN 回源 IP 段加入源站白名单（参见CDN回源节点IP地址有哪些）。

5. 检查 CDN 节点到源站的链路质量：从 CDN 节点到源站之间可能存在网络抖动、丢包或运营商路由问题。可结合 MTR/traceroute 等工具分析（需联系阿里云技术支持从 CDN 节点侧发起诊断）。

6. 调大回源读超时时间：如果源站响应耗时接近默认的 30 秒，可在 CDN 控制台调大回源HTTP请求超时时间以减少 504。该值最长可配置到 150 秒，但建议不超过 60 秒，且仅作为临时缓解手段，根本解决方式仍是优化源站响应性能。

503（Service Temporarily Unavailable）表示源站暂时无法处理请求。CDN 回源收到 503 通常由源站侧原因导致：

• 源站 Web 服务程序异常、未启动或正在重启；

• 源站负载过高（CPU、内存、连接数打满）；

• 源站配置了单 IP 访问频率限制或并发连接限制；

• 源站部署了云锁、安全狗、WAF、防火墙等安全策略拦截了 CDN 回源 IP；

• 源站进入维护模式或正在部署。

排查步骤：

1. 绑定源站直接访问复现：通过修改本地 hosts 文件将加速域名指向源站 IP 后访问，若直连源站同样返回 503，说明问题在源站侧，可排除 CDN 节点本身的问题。

2. 检查源站 Web 服务是否正常：确认 Nginx、Apache、IIS 等 Web 服务进程正在运行且监听对应端口（80/443 或自定义端口）。若服务进程异常或未启动，请重启服务并查看服务日志定位原因。

3. 检查源站负载与限流配置：源站 CPU、内存、连接数过载，或配置了单 IP 访问次数限制（如 Nginx 的 limit_req、limit_conn 模块），都可能对 CDN 回源请求返回 503。请结合业务量评估是否需要扩容或调整限流阈值。

   说明

   CDN 回源请求集中来自有限的回源节点 IP，在源站按 IP 限流的场景下容易被误判为单 IP 高频访问。建议对 CDN 回源 IP 段设置更高的限流阈值或直接豁免。

4. 检查安全策略是否拦截 CDN 回源 IP：源站的安全组、防火墙、WAF、云锁、安全狗等安全策略可能将 CDN 回源 IP 识别为异常流量并拦截。请在拦截日志中查找来自 CDN 节点 IP 的记录，将 CDN 回源 IP 段加入白名单（获取方式请参见CDN回源节点IP地址有哪些）。

5. 刷新 CDN 缓存：源站恢复后若仍访问到 503，请执行一次 URL 刷新。对于 500、502、503、504 等状态码，CDN 的缓存优先级为：源站返回 Set-Cookie 时不缓存 → 控制台配置了状态码过期时间则按配置缓存 → 否则按源站的 Pragma、Cache-Control、Expires 响应头缓存 → 上述都没有时默认缓存 1 秒。因此默认情况下 503 不会造成持续影响，但若控制台曾为 5xx 配置较长的状态码过期时间，异常响应会持续被缓存到过期，此时需手动刷新或将 5xx 的缓存时间改为 0（参见配置状态码过期时间）。

问题现象

源站通常通过 Host 请求头区分虚拟站点。若 CDN 配置的回源 HOST 与源站期望的域名不一致，源站可能返回 404、403、500 等错误。

排查步骤

1. 检查回源 HOST 是否与源站虚拟主机配置匹配

   • Nginx：检查 server_name 是否包含回源 HOST 配置的域名。

   • Apache：检查 <VirtualHost> 中的 ServerName / ServerAlias。

   • IIS：在 IIS 管理器中选择目标网站 > 绑定，检查"主机名"字段是否与回源 HOST 一致。

2. 刷新 CDN 缓存

修改回源 HOST 配置后，执行 URL 刷新以清除可能缓存的错误响应。

问题现象：网站访问出现"重定向次数过多"或"ERR_TOO_MANY_REDIRECTS"错误，或部分图片、CSS、JS 等资源加载失败。

问题原因：源站主动响应了 HTTP→HTTPS 的强制跳转（常见于宝塔面板、WAF、Nginx 等服务的强制跳转规则），而 CDN 回源协议配置为 HTTP，请求链路形成环路：

客户端 → CDN → CDN 以 HTTP 回源（端口 80）→ 源站返回 301 跳转到 HTTPS → 未配置回源 301/302 跟随时，CDN 将 301 返回给客户端 → 浏览器跟随跳转到 HTTPS → 再次经 CDN 以 HTTP 回源 → 源站再次返回 301 → ……浏览器反复重定向，最终报 ERR_TOO_MANY_REDIRECTS；若开启了回源 301/302 跟随，CDN 节点会在回源链路上反复跟随跳转，达到跟随次数上限后将 301 返回给用户，同样形成循环。关于跟随功能的说明请参见配置回源301302跟随。

解决方案（二选一）：

• 方案 A：让 CDN 直接使用 HTTPS 协议回源。前提：源站已配置有效 SSL 证书且 443 端口正常监听。将回源端口修改为 443、回源协议设置为 HTTPS；如果源站有多域名监听，同时配置回源 SNI 和回源 HOST 为加速域名或源站域名。

• 方案 B：关闭源站的强制跳转，保持 HTTP 交互。登录源站服务器，关闭强制 HTTPS 跳转规则；保持 CDN 回源协议为 HTTP、端口 80 不变。客户端到 CDN 这一段仍可用 HTTPS 加密，只要 CDN 和源站的协议约定一致即可。

辅助操作（无论选哪个方案，都建议执行）：执行 URL 刷新清除已缓存的重定向响应，确保新配置立即生效。配置修改后需要下发到全网节点，通常几分钟内完成，期间部分节点可能仍返回旧的重定向响应。关于 CDN 对各类状态码的默认缓存策略，请参见配置状态码过期时间。

本条针对仅在配置回源 HOST/SNI 之后才出现重定向循环的场景；若未配置回源 HOST/SNI 就已出现重定向循环，请参见上一条“源站配置 HTTP 到 HTTPS 跳转后出现重定向循环”。其根本原因仍是源站开启了 HTTP 到 HTTPS 的强制跳转，而 CDN 以 HTTP 协议回源；修改回源 HOST/SNI 后，源站匹配到预期站点并使强制跳转规则开始生效，循环随之出现。请按以下步骤排查：

• 关闭源站上的 HTTPS 强制跳转功能：登录源站管理面板（如宝塔面板），找到 HTTPS 设置，关闭"强制HTTPS"或"HTTP到HTTPS跳转"选项。

• 确认回源 HOST 和回源 SNI 配置一致且正确：在回源配置页面，确保回源 HOST 和回源 SNI 设置为正确的域名（通常为源站域名），且两者值保持一致，使回源请求符合源站的预期。

• 刷新 CDN 缓存：调整配置后，刷新 CDN 缓存以清除已缓存的重定向响应。

该报错说明 OSS 的 Bucket 访问权限为私有（private），未携带签名的请求无法读取 Bucket 内的对象。私有 Bucket 可以起到访问鉴权的作用，避免非授权的请求盗刷流量，因此不建议为了排除此报错而将 Bucket 改为公共读。

解决方法：为加速域名开启OSS私有Bucket回源功能。开启后，CDN 会自动使用服务角色 AliyunCDNAccessingPrivateOSSRole 携带签名访问私有 Bucket，终端用户通过 CDN 访问时无需额外签名。操作路径：CDN 控制台 > 域名管理 > 目标域名 > 回源配置 > OSS 私有 Bucket 回源。

如果您的 OSS Bucket 中使用了密钥管理服务 KMS（Key Management Service）进行加密，您需要为 CDN 的回源角色额外授予使用 KMS 密钥的权限，否则 CDN 将无法解密和访问这些文件，出现 This request is forbidden by kms. 报错。

解决方法：

1. 登录 RAM控制台，在左侧导航栏选择身份管理 > 角色。

2. 在角色名称列表下找到 AliyunCDNAccessingPrivateOSSRole 角色，单击新增授权。

   说明

   如未找到该角色，说明尚未开启过 OSS 私有 Bucket 回源功能。请先参见OSS私有Bucket回源开启功能，角色会自动创建，再返回执行此步骤。

3. 在权限策略下选择系统策略，搜索并添加 AliyunKMSCryptoUserAccess，单击确认新增授权。

4. 使用刷新预热功能，待刷新任务完成后，重新访问资源。

问题现象：源站根据客户终端类型对请求做 302 跳转以提供对应界面。接入 CDN 后，第一个用户访问时 302 响应被缓存，其他不同终端设备的用户通过同一 URL 访问时，会命中第一个用户缓存的 302 页面，导致终端适配功能失效。

方案 A（推荐）：对 302 响应设置不缓存。设置第一个请求的 URL 不缓存，而对 302 跳转后的页面进行缓存。可在源站对初始页面设置不缓存（源站的不缓存策略对 CDN 具有较高优先级），只要该页面的响应中带有以下任一响应头，即可保证该页面不缓存：

• Cache-control:no-cache、no-store

• Cache-control:max-age=0

• pragma:no-cache

• Cache-control:private

方案 B：在 CDN 侧配置初始 URL 不缓存。若无法修改源站响应头，可结合 CDN 对目录和后缀名的缓存配置及优先级，单独为初始跳转 URL 配置缓存时间为 0，其他 URL 保持正常缓存。

方案 C：使用自定义 Cache Key 区分终端类型。若希望保留缓存能力而非每次回源，可配置自定义 Cache Key，将终端类型维度加入缓存键，使 PC、移动端各自拥有独立的缓存副本，配置方法请参见自定义Cache Key。

可能原因是源站依赖 URL 参数或特定的 Host 头进行逻辑判断，而 CDN 默认行为可能导致参数丢失或 Host 头不匹配。请按以下步骤排查：

1. 检查缓存规则中的 URL 参数配置：若源站依赖 URL 参数进行跳转或逻辑判断，需注意 CDN 的“忽略参数”功能。忽略参数影响的是缓存键（Cache Key），回源请求仍会携带完整的 URL 参数，因此问题不是“参数丢失导致源站无法处理”，而是“不同参数的请求命中了同一份缓存，返回了不属于当前参数的内容”。建议关闭忽略参数，或将影响业务逻辑的参数设为保留，使不同参数各自独立缓存（参见忽略参数）。

2. 将回源 HOST 配置为源站期望的域名：确保源站能正确识别请求主机头从而处理跳转逻辑。

3. 执行目录或 URL 刷新：修改配置后，执行目录刷新或 URL 刷新以使新配置生效。

问题现象：大文件下载中断、断点续传失败，或视频拖拽播放返回错误、从头播放。

问题原因：开启 Range 回源后，CDN 节点会向源站发起带 Range 头的分片请求。如果源站不支持 Range 请求（忽略 Range 头直接返回 200 和全量内容），或返回的 Content-Range 与请求的范围不匹配，就可能导致缓存异常或客户端请求失败。

排查步骤：

1. 验证源站是否支持 Range 请求：执行 curl -I -H "Range: bytes=0-1023" http(s)://源站域名/资源路径。若返回 206 Partial Content 且包含正确的 Content-Range 头，说明源站支持 Range；若返回 200 OK 并携带完整文件，说明源站忽略了 Range 请求。

2. 根据源站能力调整 Range 回源配置：若源站不支持 Range，请先改造源站使其能正确响应 206 分片，或先关闭 CDN 的 Range 回源功能，避免 CDN 发起源站无法处理的分片请求。配置路径：CDN 控制台 > 域名管理 > 目标域名 > 视频相关 > Range 回源，该开关默认未开启，详见配置Range回源。

3. 检查源站响应头是否稳定：Range 回源要求源站对同一资源返回稳定的 Content-Length 和 ETag、Last-Modified，以便 CDN 判断各分片属于同一版本的文件。如果源站动态生成内容、无法提供这些响应头，Range 回源将不可靠。

4. 确认分片缓存是否被清理：采用 Range 方式回源时，CDN 节点如果收到源站响应的非 206 状态码，会删除已缓存的分片文件（回源超时不会删除）。因此源站间歇性返回 5xx 会反复清空已缓存的分片，表现为下载反复中断、回源量异常升高，详见配置状态码过期时间。

问题现象

通过 CDN 访问时页面出现乱码，或浏览器提示解码失败（ERR_CONTENT_DECODING_FAILED）。

问题原因

• 源站返回了压缩内容（gzip/br）但未设置 Content-Encoding 响应头，CDN 将已压缩的内容再次压缩后返回，客户端解码异常。

• 源站 Content-Encoding 声明与实际编码不一致。

排查步骤

1. 对比源站与 CDN 的响应头

# 直连源站
curl -I -H "Accept-Encoding: gzip" https://<源站域名>/<资源路径>

# 经 CDN 访问
curl -I -H "Accept-Encoding: gzip" https://<加速域名>/<资源路径>

对比两侧的 Content-Encoding、Content-Length、Content-Type 是否一致。

2. 检查 CDN 智能压缩配置

若源站已返回压缩内容（响应头含 Content-Encoding: gzip），CDN 不应再次压缩。若出现双重压缩，检查 CDN 控制台"智能压缩"是否开启，或关闭 CDN 侧压缩让源站全权处理。

3. 修复源站响应头

确保源站返回压缩内容时必须同时设置正确的 Content-Encoding 头，否则 CDN 无法识别内容已压缩。

问题现象

不同用户访问同一页面时获得了其他用户的会话信息（如登录态串号），或登录后立即失效。

问题原因

源站在动态页面响应中返回了 Set-Cookie 头，若该响应被 CDN 缓存，其他用户命中缓存后会收到不属于自己的 Cookie，导致会话信息混乱。

解决方法

1. 源站对含 Set-Cookie 的响应设置不缓存

在源站侧对动态页面添加 Cache-Control: no-store 或 Cache-Control: private，防止 CDN 缓存包含用户私有信息的响应。

2. CDN 侧配置缓存规则

在 CDN 控制台为动态页面（如 .php、.jsp、/api/ 路径）配置"不缓存"规则，确保这些请求始终回源。

3. 使用 CDN 的修改入站响应头功能去除响应头

若确认 Set-Cookie 对 CDN 缓存场景无意义（如统计 Cookie），可在 CDN 侧配置修改入站响应头功能，去除 Set-Cookie 响应头后再缓存。但需确保不会影响业务逻辑。