https重定向和cdn源站证书配置分属不同层级，混淆会导致重定向循环、证书不信任及源站ip泄露；重定向应由cdn或nginx单点接管，源站证书仅在full/strict模式下必需且须含完整链，同时需用ssl_reject_handshake和防火墙限制直连。
HTTPS 重定向和 CDN 源站证书配置是两个不同层级的职责，混淆它们会导致 ERR_TOO_MANY_REDIRECTS、证书不被信任、甚至源站 IP 泄露。关键不在“要不要配 HTTPS”，而在于“谁来配、配在哪一层、配什么内容”。
重定向逻辑应由 CDN 或 Nginx 单点接管
CDN（如 Cloudflare）和 Nginx 都能做 HTTP→HTTPS 跳转，但不能同时启用——否则形成循环跳转。
- 若使用 Cloudflare 的 Full (Strict) 模式，建议关闭 Nginx 的 80 端口 return 301 规则，改由 CDN 控制台开启「始终使用 HTTPS」
- 若选择 Flexible 模式（不推荐），Nginx 必须禁用所有 HTTPS 强制跳转，否则会因收到 HTTP 请求又跳 HTTPS 而死循环
- 宝塔面板用户需特别注意：后台勾选「强制 HTTPS」会自动注入 return 301 规则，务必手动删除并关闭该开关，避免与 CDN 冲突
源站证书只在 Nginx 443 端口生效，且仅对 Full/Strict 模式必要
源站证书不是“可有可无的装饰”，而是 Full (Strict) 模式下 Cloudflare 回源时 TLS 握手的必需凭证。
- Flexible 模式下，Cloudflare 到源站走 HTTP，Nginx 不需要也不该监听 443 或部署证书
- Full 模式允许回源 HTTPS，但不校验证书有效性；适合测试环境或自签名证书场景
- Full (Strict) 要求证书必须由受信 CA 签发、域名匹配、未过期；Let’s Encrypt 是主流选择，路径需正确配置在 ssl_certificate 和 ssl_certificate_key 中
证书链完整性影响小程序等严格环境
浏览器常自动补全中间证书，但微信小程序、iOS/Android 原生网络库不会——证书链缺失会导致请求直接失败。
- Nginx 的 ssl_certificate 文件必须包含站点证书 + 全部中间证书（按顺序拼接），不能只放站点证书
- 可用 openssl 命令验证：openssl s_client -connect your-domain.com:443 -servername your-domain.com | openssl x509 -noout -text，确认输出中 Subject 和 Issuer 连续可追溯至根 CA
- SSLLabs 测试结果中若提示 “Chain issues”，即为证书链不完整，需重新合并 fullchain.pem
源站暴露风险与 ssl_reject_handshake 防护
即使启用了 CDN，若 Nginx 对公网开放 443 端口且未限制访问来源，攻击者仍可通过扫描 IP 直连获取证书并反推域名。
- 推荐做法：在 Nginx 的 443 server 块中添加 ssl_reject_handshake on;（Nginx ≥1.25.5），彻底拒绝非预期 TLS 握手
- 配合防火墙规则（如 ufw 或云厂商安全组），仅允许 CDN 官方 IP 段（如 Cloudflare 的 173.245.48.0/20）访问 443 端口
- 避免在 80 端口返回 301 到 https://$host —— $host 可能被 CDN 回源时带端口污染，应硬编码为 https://example.com
