客户实际访问的完整域名,例如 www.example.com。中国大陆线路需先完成 ICP 备案。
Before You Start
开始前先准备这些信息
资料齐全后再创建站点,能避免配置到一半才发现没有 DNS 权限、源站端口不通或证书不完整。
准备源站 IP 或后端域名、业务端口,以及源站网站实际识别的 Host。
访客使用 HTTPS 时,准备覆盖业务域名的完整证书链和私钥;HTTPS 回源还要确认源站证书有效。
确认可以修改域名解析,并记录当前 A、AAAA 或 CNAME 的类型、值和 TTL,便于回滚。
先确认业务边界:如果网站包含 WebSocket、大文件上传、长连接、支付回调或特殊端口,请在切换前确认套餐与节点是否支持。不要等正式切流后再测试。
Quick Start
按 6 步完成第一次接入
接入通常不需要修改网站程序。核心链路是“访客访问业务域名,CDN 收到请求后再访问源站”。
- 确认源站可以独立访问先验证源站 IP、端口、Host、页面和证书正常。如果源站本身已经 502,接入 CDN 后仍会失败。完成标准:直连源站能返回正确网站,状态码为预期的 200 或合理跳转。
- 在控制台添加加速域名只填写完整主机名,例如
www.example.com,不要填写https://、路径或参数。完成标准:控制台生成该域名专用的 CNAME 地址。 - 填写源站与回源 Host源站地址填真实后端 IP 或独立源站域名;回源 Host 填源站 Web 服务能够识别的网站域名。完成标准:源站地址不能与加速域名形成解析回环。
- 选择端口与回源协议HTTP 常用 80,HTTPS 常用 443。自定义端口必须与源站真实监听端口一致,并确认防火墙已放行。完成标准:节点能够按所选协议访问源站。
- 配置证书、缓存与防护先使用保守设置:动态目录不缓存,CC 规则不要一开始就设得过严,HTTPS 证书生效后再强制跳转。完成标准:首页、登录、接口和静态资源均符合预期。
- 测试通过后切换 CNAME先使用控制台测试方式或临时 hosts 验证,再修改正式 DNS。切换后持续观察状态码、回源和缓存。完成标准:公共 DNS 返回平台分配的 CNAME,真实业务功能通过验收。
控制台字段怎么填
www.example.com客户实际访问的域名。不要带协议、斜杠、端口或页面路径。
IP源站有固定公网 IP 时选 IP;使用后端域名时,该域名不能再解析回当前加速域名。
192.0.2.10填写真实后端地址,不要填 CDN 节点 IP,也不要填控制台分配的 CNAME。
443必须与源站实际监听端口一致。HTTPS 通常为 443,HTTP 通常为 80。
www.example.com通常填写业务域名;如果源站虚拟主机使用其他域名,则填写源站实际绑定的域名。
HTTPS源站证书有效且端口支持 TLS 时选 HTTPS;源站只支持 HTTP 时选 HTTP。
最容易填错的是回源 Host:同一台源站可能托管多个网站,Host 填错时常见表现是 404、默认欢迎页或证书域名不匹配。
HTTPS & Origin
分清两段 HTTPS,再配置回源
访客到 CDN 和 CDN 到源站是两条独立连接。访客能打开 HTTPS,不代表节点正在使用 HTTPS 回源。
两张证书分别负责什么
| 位置 | 保护链路 | 证书需要覆盖 | 常见问题 |
|---|---|---|---|
| 边缘证书 | 访客 → 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
- 记录旧值保存当前 A、AAAA 或 CNAME 的主机记录、记录值、TTL 和线路设置,建议同时截图。
- 提前降低 TTL至少提前一个“旧 TTL”周期将 TTL 调整到 300 秒左右。临切换才修改不会让已经缓存的旧记录立刻失效。
- 保留回滚入口测试期间不要删除源站和旧解析资料,也不要先收紧源站防火墙。
第二步:切换前测试
优先使用控制台提供的测试方式。如果需要使用 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.comhosts 左侧必须是测试节点 IP,不是源站 IP,也不能填写 CNAME 域名。测试 IP 仅用于临时验证,完成后要删除该行,避免以后一直固定到单个节点。
第三步:按清单验收
- HTTP 与 HTTPS 都按预期打开
- 证书覆盖当前业务域名
- 首页、图片、CSS 和 JS 正常
- 登录、退出和用户中心正常
- API、上传、回调和 WebSocket 正常
- 源站日志能看到 CDN 回源请求
- 静态缓存与动态不缓存符合预期
- CC 规则没有误拦截正常访客
第四步:在 DNS 面板添加 CNAME
www接入 www.example.com 时通常填 www;具体名称以 DNS 服务商界面为准。
CNAME同一主机记录不能同时保留冲突的 A、AAAA 和 CNAME。
assigned-name.cdn8.com完整复制控制台分配的地址,不要加 http://、端口或路径。
300 秒切换稳定后可恢复原 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 或无法登录服务器。
- 获取当前完整回源网段从控制台或支持渠道获取平台当前公布的完整回源 IP 网段。不要根据日志中看到的单个节点 IP 建白名单。
- 先添加允许规则允许完整回源网段访问网站实际使用的 80、443 或自定义业务端口,同时保留自己的固定运维 IP。
- 再次通过 CDN 验证检查首页、动态接口、上传、回调和备用源站。确认没有回源失败后,再拒绝其他公网来源访问业务端口。
- 保留撤销方案记录变更前规则并确认控制台、SSH 或云厂商安全组仍可进入。出现异常时先恢复网络入口,再继续排查。
不要照搬网站端口规则到 SSH、宝塔或其他运维端口。网站白名单通常只针对业务端口;修改 22、面板端口或云安全组前,必须先确认备用登录方式。
- 源站 IP 隐藏清理不再使用的历史 DNS 记录;源站曾长期暴露时,评估更换公网 IP。
- 后台使用独立域名管理后台与公开网站分离,限制访问来源,不与公开站点共用宽泛规则。
- 真实访客 IP只信任来自平台回源网段的访客 IP 请求头;请求头名称和服务器配置以控制台当前文档为准。
- 持续更新白名单平台回源网段发生变化时要同步更新防火墙,不要把首次配置当作永久不变。
Troubleshooting
按现象排查常见问题
一次只改一项并记录结果。连续更换源站、协议、DNS 和防护规则,会让问题更难定位。
- 执行
nslookup -type=CNAME 业务域名,确认结果是否指向控制台分配地址。 - 检查同名 A、AAAA 或旧 CNAME 是否仍存在,记录值中是否误加协议、空格或路径。
- 确认修改的是当前域名实际使用的 DNS 服务商,并等待旧 TTL 过期。
- 先判断错误发生在访客到 CDN,还是 CDN 到源站。
- 访客端检查边缘证书是否覆盖业务域名、是否已生效、证书链是否完整。
- HTTPS 回源检查源站证书有效期、回源 Host、SNI 和 443 端口;不要用跳过证书校验长期掩盖问题。
- 核对访客协议、回源协议和源站强制 HTTPS 是否一致。
- 检查源站是否正确识别代理传递的访客协议,避免把 HTTPS 访客误判为 HTTP。
- 临时关闭一处跳转规则验证,定位后恢复统一跳转策略。
- 用源站验证命令带上正确 Host,确认源站本身能返回目标网站。
- 核对控制台回源 Host 是否与 Nginx、Apache、IIS 或宝塔站点绑定域名一致。
- 检查源站路径重写和多站点虚拟主机规则。
- 查看 CDN 的 CC、防盗链、地区和访问控制日志,再检查源站 WAF 日志。
- 确认请求是否带有登录 Cookie、Referer、API 鉴权或非常规 User-Agent。
- 只临时关闭一条可疑规则并限定测试范围,定位后恢复防护。
- 核对源站 IP、端口、回源协议和回源 Host,使用本文命令直连验证。
- 检查云安全组、防火墙是否放行平台完整回源网段,源站 Web 服务是否正在监听。
- 502 多见于连接或协议失败;504 多见于源站响应过慢。继续检查 CPU、内存、连接数、数据库和上游接口。
- 确认源站直连是否已经是新内容,避免刷新 CDN 后仍从源站取回旧版本。
- 查看该 URL 是命中缓存还是回源,再定向刷新准确 URL。
- 检查查询参数、缓存键和浏览器本地缓存;静态文件长期使用版本化文件名。
- 将动态路径设为不缓存,确认 Cookie、Authorization 和查询参数没有被错误处理。
- 检查请求体大小、上传超时、WebSocket 开关与连接超时是否符合业务需要。
- 对比直连源站与 CDN 访问结果,并提交完整 URL、时间、状态码和请求 ID。
联系支持前准备这些信息
信息越完整,越容易区分 DNS、节点规则和源站问题。不要通过普通聊天发送服务器密码、证书私钥或控制台密码。
域名|完整 URL|北京时间|地区/运营商|状态码/请求 ID|源站直连结果|最近改动资料准备好了?从控制台创建站点
完成测试和验收后再切换正式 DNS,遇到问题可携带报障模板联系支持。
