不少团队把业务源站部署在银河麒麟上，前端接CloudFront做CDN加速。当缓存时间到期或者文件第一次被访问时，不同区域的边缘节点会各自向源站请求同一份资源，源站短时间内可能收到大量重复请求。CloudFront Origin Shield通过在边缘节点和源站之间再加一层集中缓存，能够把这类重复回源合并掉，让源站只处理少量来自Origin Shield区域的请求。对于跑在银河麒麟上的Nginx或Apache源站，这项功能不需要改动业务代码，但需要在源站缓存策略、安全组放行和分配配置上做一些配合。
Origin Shield的回源合并机制
CloudFront默认的回源链路是用户访问就近的边缘节点，边缘节点如果本地没有缓存，就向源站发起HTTP请求。问题在于，同一个文件可能会被多个边缘节点同时回源，例如一个刚发布的热点文件，东京、新加坡、法兰克福的边缘节点几乎同一时间都来拉取。源站如果QPS上限不高，就可能被这些重复请求打满。
Origin Shield相当于在边缘节点和源站之间指定一个额外的缓存层。启用后，边缘节点在本地缓存未命中时，不再直接回源，而是先向Origin Shield所在的区域节点请求。Origin Shield内部维护一份聚合缓存，只有它自己未命中时才会向源站回源。这样源站看到的请求数量会从多个边缘节点的并行回源变成少量集中请求，尤其对带宽有限、按请求数计费或后端业务连接池较小的银河麒麟源站非常友好。
需要注意的是，Origin Shield不是再增加一层普通CDN节点，它的主要作用不是离用户更近，而是离源站更近。选择Origin Shield区域时，通常要选择与源站网络距离最近的可用区域，减少回源建立连接和传输的时间。举例来说，源站部署在华南机房，Origin Shield可以选择新加坡或香港区域；源站在欧洲，则选择法兰克福等区域。
银河麒麟源站如何设置缓存响应头
银河麒麟V10默认软件源里通常可以安装Nginx或Apache，本文以Nginx为例。源站要让CloudFront和Origin Shield知道哪些内容可以缓存多久，最直接的方式是通过Cache-Control响应头。对于静态资源，建议同时给出max-age和s-maxage，其中max-age给浏览器使用，s-maxage给CloudFront和Origin Shield这类共享缓存使用。
下面这段Nginx配置可以放在server或location块中，针对图片、CSS、JS等静态目录设置较长的共享缓存时间：
location /assets/ {
add_header Cache-Control "public, max-age=3600, s-maxage=86400";
add_header Vary "Accept-Encoding";
try_files $uri =404;
}
这里s-maxage=86400表示共享缓存可以保留一天，而浏览器本地只保留3600秒。这样既能让Origin Shield长时间减少回源，又能避免用户终端缓存过期后迟迟拿不到新版本。除了Cache-Control，源站还可以保留Last-Modified或ETag响应头，让Origin Shield在缓存过期后通过条件请求确认资源是否变化。Nginx默认对静态文件会发送Last-Modified，如果后端是动态应用返回文件流，需要检查响应头中是否包含这些验证字段。
可以使用curl直接查看源站响应头，确认配置是否生效：
curl -I http://127.0.0.1/assets/app.js
如果返回中包含Cache-Control: public, max-age=3600, s-maxage=86400，说明源站已经通过共享缓存规则。需要特别提醒的是，如果响应头中出现Set-Cookie、private或no-store，CloudFront可能不会缓存该响应，Origin Shield也无法合并回源。对于登录页、接口响应这类动态内容，建议单独设置缓存策略，不要把整套站点的默认规则都设为不可缓存。
创建CloudFront分配并启用Origin Shield
在AWS CloudFront控制台创建分配时，Origin设置中填入银河麒麟源站的域名或公网IP。Origin domain可以是Nginx暴露的HTTPS域名，也可以是源站负载均衡的域名。源站协议最好选择HTTPS only，避免回源流量被明文传输。如果源站使用自签名证书或私有CA签发证书，需要在CloudFront中关闭证书校验或上传对应CA，但生产环境更建议使用公开信任的证书。
Origin Shield的开关位于同一Origin配置区域。勾选启用后，从区域下拉列表中选择一个离源站最近的AWS区域。控制台会显示该区域名称，如亚太地区（新加坡）。保存分配后，CloudFront通常需要几分钟完成部署。也可以使用CloudFormation或Terraform管理，下面是CloudFormation中启用Origin Shield的片段：
Resources:
KylinOriginDistribution:
Type: AWS::CloudFront::Distribution
Properties:
DistributionConfig:
Enabled: true
Origins:
- Id: kylin-origin
DomainName: origin.ipipp.com
OriginShield:
Enabled: true
OriginShieldRegion: ap-southeast-1
DefaultCacheBehavior:
TargetOriginId: kylin-origin
ViewerProtocolPolicy: redirect-to-https
AllowedMethods:
- GET
- HEAD
CachedMethods:
- GET
- HEAD
ForwardedValues:
QueryString: false
Cookies:
Forward: none
这段配置中OriginShieldRegion可以根据实际源站位置调整。部署完成后，CloudFront会为分配生成一个dxxxx.cloudfront.net域名，用户访问该域名即可经过边缘节点和Origin Shield到达银河麒麟源站。
安全组方面，银河麒麟上如果启用了firewalld或iptables，需要放行CloudFront IP段访问源站的80或443端口。AWS会发布CloudFront的IP地址范围，可以在源站写一个定时脚本，拉取IP列表并更新防火墙规则。不要只放行某一个区域的少量IP，因为Origin Shield和边缘节点使用的IP都在CloudFront地址范围内，少放行一段就可能导致部分用户回源失败。
通过日志和指标确认回源合并效果
Origin Shield是否真正生效，最直观的是观察银河麒麟源站的Nginx访问日志。启用之前，同一个URI会来自大量不同IP，而且时间非常集中；启用之后，来源IP会明显变少，主要集中在一到两个网段，并且请求间隔更平稳。Nginx默认日志格式包含$remote_addr，可以用下面命令查看来源IP分布：
sudo tail -n 1000 /var/log/nginx/access.log | awk '{print $1}' | sort | uniq -c | sort -nr | head -20
如果看到某一两个IP段占了绝大多数回源请求，说明Origin Shield已经在合并请求。也可以在CloudFront控制台查看分配监控指标，重点关注Origin请求数、缓存命中率和源站延迟。启用Origin Shield后，源站请求数通常会先下降，但命中率可能不会立刻上升，因为边缘节点和Origin Shield都要先经历缓存预热阶段。
另外，CloudFront响应头中带有X-Amz-Cf-Id，但用户侧无法直接判断请求是否经过Origin Shield。源站侧可以检查回源请求的来源，如果来源属于所配置的Origin Shield区域，就说明链路正确。如果回源请求仍然来自大量不同边缘节点IP，需要检查分配是否保存成功，或者是否有多个分配分别开启了不同的Origin Shield区域。
回源失败与命中率低的常见原因
配置完成后，偶尔会遇到源站返回502或超时。第一个要排查的是银河麒麟的防火墙和安全组。如果源站只放行了少量IP，Origin Shield发起回源时使用的IP可能不在放行范围内。此时可以临时查看Nginx错误日志：
sudo tail -f /var/log/nginx/error.log
如果日志中频繁出现连接超时或被拒绝，多半是网络策略问题。第二个常见原因是回源Host头不匹配。源站Nginx如果配置了虚拟主机，会通过Host头路由到不同站点。CloudFront默认会使用与源站域名一致的主机名，但如果源站通过IP回源，或者CDN改写Host头，就可能导致源站返回404或证书错误。可以在CloudFront行为设置中明确指定回源Host。
命中率低通常和源站响应头有关。若源站返回Cache-Control: no-cache或private，CloudFront即便配置了较长的默认TTL，也可能按更保守的规则处理。还有的情况是查询字符串过多、Cookie被转发、URI不区分大小写等，导致同一资源的缓存键不同。可以通过CloudFront缓存策略把不影响内容的查询参数排除掉，减少缓存键碎片。
CloudFront Origin Shield银河麒麟CDN回源优化修改时间：2026-09-28 23:42:31