Nginx作为源站时，Akamai边缘节点会根据缓存策略决定是否需要回源。一旦本地缓存不存在或已过期，边缘会向源站发起回源请求，源站返回完整响应后由边缘缓存并分发。回源流量过高会导致源站带宽吃紧、响应变慢，而回源优化就是要从缓存决策、传输压缩、连接复用和监控调优几个维度同时下手，让每次回源都尽量轻量。
一、用响应头明确缓存边界
Nginx返回内容时携带的Cache-Control、Expires、ETag和Last-Modified会直接影响Akamai的缓存行为。很多源站没有显式设置这些头，或者只用了浏览器缓存相关的max-age，导致共享缓存无法判断合理TTL。对静态资源应该同时指定public和s-maxage，让边缘节点按共享缓存时间保存；stale-while-revalidate则允许缓存过期后先返回旧内容，同时后台回源更新，可以明显降低用户侧延迟。
除了TTL，验证头也很关键。Nginx默认会为静态文件生成ETag和Last-Modified，但需确认是否保持稳定。当Akamai缓存过期后发起条件请求，源站若能返回304 Not Modified，就避免了重新传输完整响应体，这对体积较大的下载文件尤其有用。配置中保持etag on，并设置if_modified_since exact，避免时间精度导致无谓的重复响应。
动态接口则需要相反策略。登录态、支付回调、用户个性化数据一旦被Akamai缓存，可能造成跨用户数据泄漏。应在Nginx响应中显式返回Cache-Control: no-store或private，同时避免生成Last-Modified等验证头。对于带有Set-Cookie的响应，Akamai默认也可能缓存，需要在Nginx侧剥离或通过Property Manager规则跳过缓存。
server {
listen 443 ssl http2;
server_name origin.ipipp.com;
keepalive_timeout 65;
keepalive_requests 10000;
location /assets/ {
root /var/www;
expires 30d;
add_header Cache-Control "public, max-age=2592000, s-maxage=2592000, stale-while-revalidate=86400";
add_header Vary "Accept-Encoding";
etag on;
if_modified_since exact;
}
location /api/ {
proxy_pass http://backend;
add_header Cache-Control "no-store";
}
}
上述配置中，add_header Vary "Accept-Encoding"需要与压缩配置联动，否则Akamai可能把压缩版本返回给不支持压缩的客户端。对于已经开启gzip_vary on的情况，Nginx会自动添加Vary: Accept-Encoding，此时不需要重复add_header。
二、压缩与连接复用降低回源开销
回源链路上的数据传输量直接影响带宽成本和响应速度。Nginx对文本类资源开启Gzip或Brotli压缩后，Akamai回源请求同样能收到压缩响应。常见问题是普通Nginx配置只压缩浏览器直连请求，而不压缩代理请求，因为没有设置gzip_proxied any。当Akamai作为代理回源时，如果gzip_proxied未开启，Nginx可能返回未压缩内容，等于浪费了边缘到源站这一段带宽。
压缩配置需要覆盖常见文本类型，并设置最小压缩长度，避免小文件压缩反而增加CPU消耗。压缩级别建议在5到6之间平衡压缩率与耗时。Brotli压缩率更高，但需要额外模块，如果Akamai边缘已支持Brotli处理，源站可以只提供Gzip作为基础。
gzip on; gzip_vary on; gzip_proxied any; gzip_comp_level 6; gzip_min_length 1024; gzip_types text/plain text/css application/json application/javascript application/xml image/svg+xml;
连接复用同样关键。Akamai回源使用HTTPS时，每次完整TLS握手会消耗一到两个RTT，对于短小频繁的回源请求影响很大。Nginx侧应启用HTTP/2并调大keepalive_requests，让Akamai边缘节点与源站之间保持长连接。同时优化TLS会话缓存，设置ssl_session_cache shared:SSL:20m和ssl_session_timeout 1d，可以让后续回源复用会话，跳过证书协商。
如果Nginx前面还有负载均衡或防火墙，需要确认它们的空闲连接超时比Nginx短，否则长连接可能被中间设备提前断开，反而增加错误重试。排查时可以观察Nginx错误日志中是否有大量连接被对端重置的记录。
三、Akamai侧缓存规则与回源去重
回源优化不能只靠Nginx，Akamai缓存规则的颗粒度同样重要。默认情况下，带查询参数的请求可能被视为不同对象，导致同一个资源因为utm_source等跟踪参数变化而反复回源。在Akamai Property Manager中，可以针对静态路径设置忽略部分查询参数，让缓存键只包含有效参数。对于版本号资源，则应保留参数或路径差异，避免错误复用。
TTL策略上，建议静态资源设置较长TTL，例如7天到30天，而HTML页面设置较短TTL，例如5到15分钟，既保证更新及时，又减少高频回源。如果源站响应头已经包含合理TTL，可以保持honor origin Cache-Control；如果源站没有缓存头，则在Akamai规则中设置默认TTL，避免边缘默认不缓存。
Akamai还提供回源合并或请求折叠能力，当多个边缘节点同时请求同一未缓存对象时，可以在网络层合并为一次回源，降低源站瞬时压力。建议在属性配置中开启类似功能，同时结合stale-if-error保证源站异常时仍可返回过期内容。
四、通过响应头与日志排查回源问题
优化之后需要持续观察命中率。用户侧响应头中的X-Cache通常会显示TCP_HIT、TCP_MISS或TCP_REFRESH_HIT，通过抽样检查可以初步判断边缘是否回源。更系统的方式是查看Akamai日志中的cache_status字段，统计不同路径的命中率，优先优化命中率低但流量大的对象。
在源站Nginx侧，虽然看不到边缘命中状态，但可以通过日志记录回源请求的URL、状态码和响应大小，找到哪些路径频繁触发回源。结合Nginx日志分析命令可以快速定位问题对象。
awk '{print $7}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head -20
curl -sI https://origin.ipipp.com/assets/app.js | grep -iE 'cache-control|etag|vary|content-encoding'
使用上述命令时，可以把$7替换成实际日志格式中URL字段的位置。分析结果如果显示某个JS或图片文件回源次数异常，可能是Akamai缓存命中率低，需要检查缓存键、TTL或Vary头。例如响应头中缺少Vary: Accept-Encoding，边缘可能为不同Accept-Encoding分别回源，导致回源次数翻倍。
另外，源站升级或迁移后，大批量缓存失效会引发回源潮。此时可以通过Nginx限速模块控制单IP回源速率，防止源站过载，但注意不要限制Akamai正常回源请求。更稳妥的方式是提前设置较长的stale-while-revalidate和stale-if-error窗口，让边缘在源站恢复前继续提供旧内容。
整体来看，Nginx与Akamai的回源优化是一个动态调整过程。先把Nginx侧响应头、压缩和连接复用配置到位，再结合Akamai缓存规则和日志数据持续修正，通常能把回源请求量降低一半以上，同时缩短缓存未命中的尾部延迟。
Nginx回源优化Akamai CDN缓存策略修改时间：2026-09-27 15:20:36