Integration Guide

高防 CDN 新手接入指南

从准备资料、填写源站到测试和切换 CNAME,每一步都给出示例与完成标准。第一次接入也可以按顺序逐项核对。

Before You Start

开始前先准备这些信息

资料齐全后再创建站点,能避免配置到一半才发现没有 DNS 权限、源站端口不通或证书不完整。

业务域名

客户实际访问的完整域名,例如 www.example.com。中国大陆线路需先完成 ICP 备案。

源站信息

准备源站 IP 或后端域名、业务端口,以及源站网站实际识别的 Host。

HTTPS 证书

访客使用 HTTPS 时,准备覆盖业务域名的完整证书链和私钥;HTTPS 回源还要确认源站证书有效。

DNS 权限与备份

确认可以修改域名解析,并记录当前 A、AAAA 或 CNAME 的类型、值和 TTL,便于回滚。

加速域名www.example.com
源站 IP192.0.2.10
源站端口443
分配的 CNAMEassigned-name.cdn8.com

先确认业务边界:如果网站包含 WebSocket、大文件上传、长连接、支付回调或特殊端口,请在切换前确认套餐与节点是否支持。不要等正式切流后再测试。

Quick Start

按 6 步完成第一次接入

接入通常不需要修改网站程序。核心链路是“访客访问业务域名,CDN 收到请求后再访问源站”。

  1. 确认源站可以独立访问先验证源站 IP、端口、Host、页面和证书正常。如果源站本身已经 502,接入 CDN 后仍会失败。完成标准:直连源站能返回正确网站,状态码为预期的 200 或合理跳转。
  2. 在控制台添加加速域名只填写完整主机名,例如 www.example.com,不要填写 https://、路径或参数。完成标准:控制台生成该域名专用的 CNAME 地址。
  3. 填写源站与回源 Host源站地址填真实后端 IP 或独立源站域名;回源 Host 填源站 Web 服务能够识别的网站域名。完成标准:源站地址不能与加速域名形成解析回环。
  4. 选择端口与回源协议HTTP 常用 80,HTTPS 常用 443。自定义端口必须与源站真实监听端口一致,并确认防火墙已放行。完成标准:节点能够按所选协议访问源站。
  5. 配置证书、缓存与防护先使用保守设置:动态目录不缓存,CC 规则不要一开始就设得过严,HTTPS 证书生效后再强制跳转。完成标准:首页、登录、接口和静态资源均符合预期。
  6. 测试通过后切换 CNAME先使用控制台测试方式或临时 hosts 验证,再修改正式 DNS。切换后持续观察状态码、回源和缓存。完成标准:公共 DNS 返回平台分配的 CNAME,真实业务功能通过验收。

控制台字段怎么填

字段示例填写说明
加速域名www.example.com

客户实际访问的域名。不要带协议、斜杠、端口或页面路径。

源站类型IP

源站有固定公网 IP 时选 IP;使用后端域名时,该域名不能再解析回当前加速域名。

源站地址192.0.2.10

填写真实后端地址,不要填 CDN 节点 IP,也不要填控制台分配的 CNAME。

源站端口443

必须与源站实际监听端口一致。HTTPS 通常为 443,HTTP 通常为 80。

回源 Hostwww.example.com

通常填写业务域名;如果源站虚拟主机使用其他域名,则填写源站实际绑定的域名。

回源协议HTTPS

源站证书有效且端口支持 TLS 时选 HTTPS;源站只支持 HTTP 时选 HTTP。

最容易填错的是回源 Host:同一台源站可能托管多个网站,Host 填错时常见表现是 404、默认欢迎页或证书域名不匹配。

HTTPS & Origin

分清两段 HTTPS,再配置回源

访客到 CDN 和 CDN 到源站是两条独立连接。访客能打开 HTTPS,不代表节点正在使用 HTTPS 回源。

01访客访问 www.example.com
02CDN 节点清洗、缓存与转发
03源站192.0.2.10:443

两张证书分别负责什么

位置保护链路证书需要覆盖常见问题
边缘证书访客 → CDN加速域名 www.example.com未生效就强制 HTTPS,访客会看到证书错误
源站证书CDN → 源站回源 Host / SNI 使用的域名过期、链不完整或域名不匹配会导致回源 TLS 失败

回源协议怎么选

模式适用情况必须确认
HTTP 回源源站只开放 HTTP,或临时排查 TLS 问题端口正确,源站不会因协议判断反复跳转
HTTPS 回源登录、交易、API 和需要全链路加密的业务源站证书有效、证书链完整、SNI 与回源 Host 正确
协议跟随源站同时支持 HTTP 和 HTTPS两个端口都可用,两个协议返回的业务行为一致

切换前验证源站

将示例中的 IP、端口和域名替换为实际值。Windows 可使用系统自带的 curl.exe;macOS 和 Linux 使用 curl

curl.exe -I -H "Host: www.example.com" http://192.0.2.10:80/
curl.exe -I --resolve www.example.com:443:192.0.2.10 https://www.example.com/

什么结果算正常:返回预期的 200,或业务本来就需要的 301/302;HTTPS 没有证书报错;页面 Host 正确,不是服务器默认站点。

出现循环跳转:先检查客户端协议、回源协议、源站强制 HTTPS 和代理请求头。典型错误是节点使用 HTTP 回源,而源站又根据错误的协议判断不断跳回 HTTPS。

Cache

第一次接入先用保守缓存规则

缓存的目标是减少重复回源,不是把所有内容都缓存。登录态、订单、支付和 API 一旦误缓存,可能把错误内容返回给其他访客。

内容类型示例路径初始建议更新方式
图片、字体、CSS、JS*.jpg / *.woff2 / *.css / *.js缓存 1 至 7 天文件名带版本号,发布后定向刷新
安装包与公开下载/download/ /assets/按更新频率设置长缓存新文件使用新名称,必要时预热
公开 HTML/news/ /article/遵循源站或设置短缓存内容更新后刷新具体 URL
登录、后台、订单、支付/login /admin /order /pay不缓存始终回源
API、上传、带鉴权请求/api/ /upload/默认不缓存确认业务允许后再单独优化
  • 查询参数确认不同参数是否代表不同内容,例如商品 ID、语言和版本号,不要错误合并缓存键。
  • Cookie 与登录态带登录 Cookie 或 Authorization 的请求默认不缓存,除非已经明确验证业务逻辑。
  • 源站缓存头首次接入可遵循 Cache-Control;源站返回 Set-Cookie 时要特别检查是否应缓存。
  • 命中验证从控制台日志或平台响应头查看命中与回源标记,具体标记名称以控制台当前展示为准。
curl.exe -I https://www.example.com/assets/app.css

内容更新后优先刷新具体 URL,不要把“清空全站缓存”当作日常发布流程。静态文件使用版本化名称更稳定。

Test & DNS

先测试,再切换正式 CNAME

不要创建完站点就立即修改公共 DNS。先验证完整链路,并保存旧解析,出现异常时才能快速恢复。

第一步:保存旧解析并降低 TTL

  1. 记录旧值保存当前 A、AAAA 或 CNAME 的主机记录、记录值、TTL 和线路设置,建议同时截图。
  2. 提前降低 TTL至少提前一个“旧 TTL”周期将 TTL 调整到 300 秒左右。临切换才修改不会让已经缓存的旧记录立刻失效。
  3. 保留回滚入口测试期间不要删除源站和旧解析资料,也不要先收紧源站防火墙。

第二步:切换前测试

优先使用控制台提供的测试方式。如果需要使用 hosts,请先解析平台分配的 CNAME,取得临时测试节点 IP。

nslookup assigned-name.cdn8.com

然后在 hosts 文件末尾临时添加一行。Windows 文件位置为 C:\Windows\System32\drivers\etc\hosts,macOS / Linux 为 /etc/hosts

203.0.113.20 www.example.com

hosts 左侧必须是测试节点 IP,不是源站 IP,也不能填写 CNAME 域名。测试 IP 仅用于临时验证,完成后要删除该行,避免以后一直固定到单个节点。

第三步:按清单验收

  • HTTP 与 HTTPS 都按预期打开
  • 证书覆盖当前业务域名
  • 首页、图片、CSS 和 JS 正常
  • 登录、退出和用户中心正常
  • API、上传、回调和 WebSocket 正常
  • 源站日志能看到 CDN 回源请求
  • 静态缓存与动态不缓存符合预期
  • CC 规则没有误拦截正常访客

第四步:在 DNS 面板添加 CNAME

DNS 字段示例填写说明
主机记录www

接入 www.example.com 时通常填 www;具体名称以 DNS 服务商界面为准。

记录类型CNAME

同一主机记录不能同时保留冲突的 A、AAAA 和 CNAME。

记录值assigned-name.cdn8.com

完整复制控制台分配的地址,不要加 http://、端口或路径。

TTL300 秒

切换稳定后可恢复原 TTL。部分服务商只提供固定档位,选择接近值即可。

根域名 example.com 通常使用主机记录 @,但部分 DNS 服务商不允许根域名直接使用 CNAME。可使用其提供的 CNAME Flattening / ALIAS,或将根域名跳转到 www 后再接入。

第五步:检查公共解析

nslookup -type=CNAME www.example.com

结果应能看到控制台分配的 CNAME。不同地区仍返回旧值时,通常是递归 DNS 缓存尚未过期;等待原 TTL,不要连续反复修改记录。

上线后观察:至少检查状态码分布、回源失败、证书、缓存命中、带宽和正常访客是否被拦截。确认稳定后再进行源站加固。

需要回滚时:将 DNS 恢复为已保存的旧 A、AAAA 或 CNAME,等待解析生效;不要先删除 CDN 站点,以免仍在使用旧缓存的访客立即失去访问路径。

Hardening

业务稳定后再收紧源站入口

源站安全加固的顺序很重要。过早拒绝公网访问、漏放回源网段或误关运维端口,都会直接造成 502 或无法登录服务器。

  1. 获取当前完整回源网段从控制台或支持渠道获取平台当前公布的完整回源 IP 网段。不要根据日志中看到的单个节点 IP 建白名单。
  2. 先添加允许规则允许完整回源网段访问网站实际使用的 80、443 或自定义业务端口,同时保留自己的固定运维 IP。
  3. 再次通过 CDN 验证检查首页、动态接口、上传、回调和备用源站。确认没有回源失败后,再拒绝其他公网来源访问业务端口。
  4. 保留撤销方案记录变更前规则并确认控制台、SSH 或云厂商安全组仍可进入。出现异常时先恢复网络入口,再继续排查。

不要照搬网站端口规则到 SSH、宝塔或其他运维端口。网站白名单通常只针对业务端口;修改 22、面板端口或云安全组前,必须先确认备用登录方式。

  • 源站 IP 隐藏清理不再使用的历史 DNS 记录;源站曾长期暴露时,评估更换公网 IP。
  • 后台使用独立域名管理后台与公开网站分离,限制访问来源,不与公开站点共用宽泛规则。
  • 真实访客 IP只信任来自平台回源网段的访客 IP 请求头;请求头名称和服务器配置以控制台当前文档为准。
  • 持续更新白名单平台回源网段发生变化时要同步更新防火墙,不要把首次配置当作永久不变。

Troubleshooting

按现象排查常见问题

一次只改一项并记录结果。连续更换源站、协议、DNS 和防护规则,会让问题更难定位。

联系支持前准备这些信息

信息越完整,越容易区分 DNS、节点规则和源站问题。不要通过普通聊天发送服务器密码、证书私钥或控制台密码。

域名|完整 URL|北京时间|地区/运营商|状态码/请求 ID|源站直连结果|最近改动

资料准备好了?从控制台创建站点

完成测试和验收后再切换正式 DNS,遇到问题可携带报障模板联系支持。

进入控制台