切换至CloudFront CDN后少量用户无法访问站点的排查咨询

以下是针对该场景的具体排查点，按优先级从用户侧到服务侧梳理：

用户侧环境排查 #

• 确认用户的网络场景：是否集中在特定运营商（如移动宽带、境外网络）、是否使用代理/VPN、企业内网等特殊环境——这类环境可能存在中间设备拦截HTTPS请求或解析异常
• 验证浏览器兼容性：让用户切换到隐私模式/清空浏览器缓存后重试，或换用不同浏览器测试；排查是否是旧版本浏览器（如IE11及以下）不支持CloudFront默认的TLS 1.2+加密协议
• 检查用户本地DNS解析：让用户执行nslookup 你的域名或dig 你的域名，对比正常用户的解析结果，确认是否解析到了异常的CloudFront边缘节点

CloudFront配置细节排查 #

• 检查TLS版本配置：进入CloudFront分发设置的「SSL/TLS证书」部分，确认是否开启了对TLS 1.0/1.1的支持（如果需要兼容旧设备），部分用户的旧设备/浏览器仅支持低版本TLS，会导致握手失败
• 排查边缘节点缓存异常：虽然仅缓存assets文件夹，但可能存在边缘节点残留了上线前的错误缓存（如404响应），可手动对/assets/*路径执行缓存失效操作，再让用户测试
• 检查源站信任配置：如果回源使用HTTPS，确认EC2上的SSL证书是否是CloudFront信任的（如AWS ACM证书或公开CA签发的证书），避免因证书不被信任导致回源失败
• 核对源站访问控制：检查EC2的安全组/防火墙规则，是否允许CloudFront所有边缘节点的IP访问——虽然整体流量正常，但可能部分边缘节点IP未被加入白名单，导致对应区域的用户请求失败

回源EC2服务排查 #

• 分析Web服务器日志：不要只看CloudFront日志，查看EC2上Nginx/Apache等Web服务器的访问日志，过滤用户反馈时间段的请求，检查是否存在针对特定用户的4xx/5xx响应，或请求头（如Host、User-Agent）异常的情况
• 检查服务器资源与连接限制：查看EC2的CPU、内存、磁盘IO监控，确认是否有瞬时峰值；同时检查Web服务器的max_connections、worker_processes等配置，是否存在连接数耗尽导致部分用户请求被拒绝的情况
• 验证动态内容回源逻辑：确认非assets路径的请求是否正确回源到EC2，是否存在路由配置错误（如CloudFront的行为规则误将动态内容也做了缓存）

DNS与缓存TTL排查 #

• 检查DNS解析TTL：如果之前域名指向EC2，切换到CloudFront时TTL设置过长，部分用户的本地DNS可能还缓存着旧的EC2 IP，导致访问失败——可查看域名解析的TTL值，确认是否已足够让大部分用户完成解析更新
• 排查DNS解析异常：使用第三方DNS检测工具，检查不同区域、运营商的解析结果，确认是否存在部分节点解析失败或指向错误的情况

内容的提问来源于stack exchange，提问作者Mat