CDN的价值在于把内容推到离用户最近的边缘节点，但边缘节点最终还是要回源站取数据。如果回源链路配置不当，轻则缓存命中率低、加速效果打折，重则源站IP暴露被恶意直连、用户请求绕过CDN直击源站导致防护失效。Apache作为最常见的源站服务器之一，它的回源相关配置有不少细节容易被忽略，这篇文章就把这些注意事项逐一梳理清楚。
先弄清楚回源时Apache收到的是什么请求
理解回源的关键在于换位思考：CDN边缘节点向源站发起的请求，和你浏览器直接访问源站的请求，本质上是同一种东西，都是标准的HTTP请求。但有几个字段完全不同，这正是配置问题的根源所在。
第一个差异是Host头。CDN回源时默认携带的Host头可能是加速域名，也可能需要你在CDN控制台配置成源站域名。如果Apache上的虚拟主机基于域名区分（NameVirtualHost），而回源Host指向了一个Apache没有配置的域名，请求就会落到默认虚拟主机上，返回404或者错误页面。这种问题非常典型：直接用IP访问源站正常，套上CDN就全站404，八成就是Host头对不上。
第二个差异是客户端IP。回源请求的TCP来源地址是CDN节点的IP，不是用户的真实IP。Apache日志里如果不做特殊处理，记录的全是CDN节点地址，你将无法审计、无法做基于IP的限流和封禁。CDN通常会把真实IP放在X-Forwarded-For请求头里传过来，Apache需要配置mod_remoteip模块来解析它。
第三个差异是协议。很多CDN支持边缘HTTPS、回源HTTP，或者全链路HTTPS。Apache要确保回源端口（80或443）的监听和证书配置与CDN回源方式一致，否则会出现连接被拒或证书校验失败。
获取真实客户端IP：mod_remoteip的正确配置
有些资料会教你用%{X-Forwarded-For}i这种写法直接在日志格式里取请求头，这种做法有严重安全隐患：请求头可以伪造，任何直连源站的人只要手动加一个X-Forwarded-For头，就能让日志记录任意IP，你的封禁策略会完全失效。正确的方案是使用mod_remoteip，并明确指定信任的代理网段。
配置示例如下：
# 加载模块（Apache 2.4内置，确认未被注释即可） LoadModule remoteip_module modules/mod_remoteip.so # 声明信任的CDN回源网段，只有这些地址传来的X-Forwarded-For才会被采信 RemoteIPHeader X-Forwarded-For RemoteIPInternalProxy 203.0.113.0/24 RemoteIPInternalProxy 198.51.100.15 # 让日志记录真实IP LogFormat "%a %l %u %t \"%r\" %>s %b" combined_remoteip CustomLog logs/access_log combined_remoteip
这里的网段要填你所用CDN官方公布的回源IP段，各家CDN都会在文档里提供列表，而且可能随扩容变化，建议定期核对更新。配置后可以用apachectl -t检查语法，再通过日志确认%a输出的已经是用户真实IP。
另一个相关细节是访问控制。如果你的源站只想服务CDN，不允许用户直连，可以把这些回源网段写进Require ip白名单，其余请求一律拒绝，这样即使源站域名解析泄露，恶意流量也进不来。注意别把网段写死得太窄，CDN节点扩容后新IP会被误拦。
回源 Host、缓存协商与压缩这三个高频坑点
坑点一：回源Host与虚拟主机不匹配
排查这类问题最快的办法是在Apache默认虚拟主机（第一个VirtualHost块）里加一条自定义日志，把回源请求的Host记录下来，确认CDN传的到底是什么，然后在CDN控制台把回源Host改成Apache配置中真实存在的ServerName。两边对齐后问题即可消失。也可以在Apache端用ServerAlias把可能的回源Host都接住，作为兜底手段。
坑点二：gzip压缩导致CDN缓存失效
CDN回源时会带上Accept-Encoding: gzip，Apache的mod_deflate看到后返回压缩内容。问题在于HTTP压缩和Vary头的配合：如果Apache没有正确输出Vary: Accept-Encoding，CDN可能把gzip版本的内容缓存后返回给不支持解压的客户端，或者反过来重复回源。标准写法如下：
# 显式声明压缩资源随Accept-Encoding变化 Header append Vary Accept-Encoding AddOutputFilterByType DEFLATE text/html text/plain text/css AddOutputFilterByType DEFLATE application/javascript application/json
另外一个选择是在源站关闭压缩，让CDN边缘节点做压缩，这样回源流量更小还是更大取决于内容类型，一般建议源站开启压缩并配好Vary头，因为回源带宽通常是源站的瓶颈。
坑点三：缓存控制头互相打架
CDN的缓存策略通常遵循源站的Cache-Control响应头。如果Apache的mod_expires或mod_headers设置的缓存时间和CDN控制台配置的冲突，实际生效规则可能和你预想的不一样。原则是：缓存策略只在一个地方定义，要么完全交给源站响应头，要么在CDN控制台强制覆盖，不要两边都配。对静态资源推荐源站输出明确的长缓存头：
<FilesMatch "\.(css|js|png|jpg|webp|woff2)$">
Header set Cache-Control "public, max-age=2592000"
</FilesMatch>
# HTML类动态内容禁止CDN长缓存
<FilesMatch "\.(html|php)$">
Header set Cache-Control "no-cache"
</FilesMatch>
用Apache自己做回源层或前置代理的场景
除了作为源站，Apache有时也会被用作CDN架构中的中间层，比如内部回源负载均衡或者对上游私有存储的代理。这时要用到mod_proxy，配置时有几个注意点。
ProxyPreserveHost On ProxyRequests Off ProxyPass "/static/" "http://10.0.0.10:8080/static/" retry=30 timeout=5 ProxyPassReverse "/static/" "http://10.0.0.10:8080/static/" # 传递真实客户端信息给上游 RequestHeader set X-Forwarded-Proto "https"
第一，ProxyRequests Off必须保持，这是防止Apache被滥用为开放正向代理的关键开关。第二，ProxyPreserveHost On决定转发时是否保留原始Host头，上游按域名区分站点时必须打开，否则上游会收到10.0.0.10这样的Host。第三，retry参数能避免上游短暂故障时每个请求都等待超时，建议显式设置。
如果还希望在Apache这一层做缓存，可以配合mod_cache。要特别注意CacheQuickHandler的行为差异，以及别对带有Cookie或Authorization头的响应开启缓存，否则可能出现用户A的内容推送给用户B这种严重事故。动态内容一律加Cache-Control: private或no-store来兜底。
上线前的核对清单
最后给一份可以直接过一遍的检查项：
- CDN回源Host与Apache的ServerName或ServerAlias一致；
- mod_remoteip已配置信任网段，日志记录的是真实IP；
- 源站防火墙或Require ip限制只放行CDN回源网段；
- 回源端口与协议（HTTP/HTTPS）与Apache监听配置匹配，HTTPS回源时证书有效；
- 压缩资源带Vary Accept-Encoding头；
- 缓存时长策略只在源站或CDN一端定义，避免冲突；
- 敏感路径（后台、API）确认CDN缓存规则不会缓存响应；
- 配置变更后用apachectl -t校验并观察一轮日志再收工。
回源配置的本质是让CDN和源站对请求的理解保持一致：Host是什么、客户端是谁、内容可不可以缓存。把这三件事核对清楚，绝大多数CDN接入问题都能提前规避。