服务器放在新加坡或美国，中国大陆用户打开首页还算快，登录、查询订单却一直转圈；平时访问正常，一到晚高峰或遇到攻击就频繁超时。这类问题，单看节点位置和防御带宽，很难选对高防CDN。

兼顾速度与防护，要同时验证用户到节点、节点到海外源站两段链路，再检查缓存、动态接口和攻击期间的正常业务表现。 高防CDN可以改善分发与防护，但不能替代数据库优化，也不能自动保护绕过CDN的源站入口。

选海外高防CDN前，先判断业务卡在哪一段

CDN，即内容分发网络，会通过边缘节点接收用户请求。源站则是实际运行网站程序、存放原始内容的服务器。“回源”指节点向源站获取内容。

对海外服务器来说，用户访问至少涉及两个需要分别评估的网络环节：中国大陆用户连接CDN节点，以及CDN节点连接海外源站。缓存命中时，节点可以直接返回可复用的内容；需要实时处理的请求，通常仍要经过回源和应用处理。

这些现象只是排查入口，不足以直接归因。例如，接口超时既可能来自跨境链路，也可能是数据库慢查询。没有基础记录时，可以先结合网站访问慢的排查思路，把连接、等待响应和资源下载区分开，再决定购买哪类服务。

线路怎样比较，才能代表中国大陆用户的实际体验？

节点地域要看，完整访问路径更要看

香港节点值得纳入中国大陆用户场景的测试，但“在香港”本身不是速度保证。用户接入的运营商、跨网互联、峰值拥塞，以及节点到源站的路径，都会影响最后的表现。

假设用户在广州，CDN节点在香港，源站在美国：一张已缓存的图片可能由香港节点直接返回，但一次必须回源的订单查询，仍要等待香港节点与美国源站之间的通信和后台处理。这是链路示例，不是任何厂商的实测结果。

因此，看到“CN2”“直连”“优化线路”等描述时，应该继续问：覆盖哪段链路、哪些运营商，是否适用于自己购买的套餐，以及拥塞或故障时会如何切换。某一段使用优化线路，不能推导出全部用户、全部请求都有相同效果。

按用户分布测试，不按测速点数量选服务

从现有访问日志中找出主要用户地区，再覆盖当地电信、联通、移动网络。有明显移动端流量的业务，还应保留手机网络测试。

一个可执行的比较方式是：选择代表性省份，在工作时段、晚高峰及业务高峰分别重复测试，记录网络、时间、URL、缓存状态、错误情况和样本量。来自同一机房的一百次请求，仍然不能代表一百种真实访问环境。

比较两家服务时，应使用相同版本的业务、相同源站和相近安全策略。通过双方支持的测试接入方式验证实际业务域名；如果使用测试子域名，还要核对Cookie、跨域规则和登录回调，避免把测试环境差异算到CDN头上。

不要直接把一家缓存预热后的图片，与另一家首次回源的图片放进同一张速度排名表。

同时记录耗时、失败率与业务结果

TTFB是“首字节时间”，表示从开始请求到收到响应首字节的等待。浏览器导航中的TTFB可能包含DNS解析、连接与TLS协商、重定向和等待响应等环节，因此TTFB高不能直接等同于服务器处理慢。具体统计口径可参考Google web.dev的TTFB说明。

选型时建议至少保留四类结果：

1. 典型耗时与慢请求耗时。 同时看中位数P50和P95；P95反映约95%的样本不超过的耗时，比平均值更容易暴露慢请求问题。
2. 失败与超时。 单独统计失败次数占全部尝试次数的比例，不要删除失败样本后只展示成功请求的速度。
3. 页面实际加载。 首页HTML返回快，不代表首屏图片、脚本和第三方资源都快。
4. 关键操作结果。 登录能否完成、查询是否返回正确数据、回调是否被接受，比一张低延迟截图更接近业务目标。

不存在适合所有网站的统一“合格毫秒数”。应先记录现有表现，再结合用户能接受的等待时间制定目标，并为登录、支付等关键流程单独设置验收条件。

静态缓存与动态接口，应该怎样分别优化？

能安全复用的内容，尽量减少重复回源

图片、样式表、脚本和公开下载文件，可以按更新频率制定缓存策略。这里的“命中”是指请求可以使用已有缓存响应，并非所有请求都必须重新访问海外源站。

检查缓存时，需要同时看内容是否允许共享、缓存有效期和实际命中结果。Cache-Control: no-store表示不应存储响应；未带字段限定的private表示共享缓存不应存储该响应；no-cache则允许存储，但再次使用前需要验证，不能把它理解成完全不缓存。这些含义由HTTP缓存标准RFC 9111定义。

涉及账号、订单、余额等用户专属内容，不应为了提高命中率而直接套用全站缓存。还要核对CDN规则是否覆盖源站设置，确认不会把一个用户的结果返回给另一个用户。

采购时也要问清楚：发布新版本怎样刷新缓存，首次访问如何处理，以及预热等功能是否在拟购方案中。缓存更新错误带来的旧价格、旧页面，同样属于业务故障。

必须实时处理的请求，重点看回源与应用

动态请求不能简单依靠复制一份页面来加速，但仍可能受益于更合适的网络路径、连接复用和流量调度。收益大小取决于实际链路和服务实现，需要用自己的接口验证。

建议至少选择一组公开只读接口，再在测试环境验证登录、下单和回调流程。若静态资源明显改善，而动态接口仍慢，应继续检查节点到源站的连接时间、后台处理时间及数据库负载。

CDN无法消除数据库慢查询，也无法让位于远端的实时数据不经过通信就返回。对于强交互业务，如果回源持续成为瓶颈，就需要同时评估应用部署位置、数据访问方式或区域服务架构。

怎样用命令获得可以比较的检测记录？

下面的命令适用于安装了curl的Linux或macOS终端。将示例地址替换成你有权测试的公开页面或只读接口，不要用会创建订单、发送短信的接口做重复测速。

curl -sS --connect-timeout 10 --max-time 30 \
  -D - -o /dev/null \
  -w '\nhttp_code=%{http_code}\nremote_ip=%{remote_ip}\ndns=%{time_namelookup}s\nconnect=%{time_connect}s\ntls_ready=%{time_appconnect}s\nttfb=%{time_starttransfer}s\ntotal=%{time_total}s\n' \
  'https://www.example.com/'

这条命令执行一次GET请求，显示响应头和耗时，丢弃响应正文。10秒连接超时、30秒总超时是示例限制，不是业务合格线。字段定义见curl官方文档。

重点这样读：

• http_code用于确认响应状态。200仍可能是验证页面，必须结合浏览器或响应正文判断；000表示未取得HTTP响应码，应查看curl错误信息。
• dns、connect、tls_ready都是从开始计时到对应阶段完成的累计时间，不能直接相加。
• ttfb包含收到首字节之前的等待；total是此次传输结束所用的总时间，不包括浏览器随后下载其他资源和渲染页面。
• remote_ip表示本次连接的远端IP。它可辅助核对接入路径，不能单凭IP归属地判断全部流量经过哪些机房。

命令没有自动跟随重定向。若得到301或302，先查看Location，确认最终地址，再对最终URL单独测量。遇到传输失败时，即使已经得到HTTP状态码，也应保留错误记录。

响应头还可帮助判断缓存，但字段不能跨厂商硬套。例如，Cloudflare的CF-Cache-Status: HIT表示从其缓存找到资源，MISS表示该可缓存资源未在缓存中找到并从源站获取；这是Cloudflare自己的缓存状态定义。其他服务的字段与含义，以对应厂商文档为准。

一次curl请求只能说明一个时间点、一条网络、一个资源的表现。 将同样的方法用于前面选定的地区和时段，再结合浏览器与业务日志，才有采购参考价值。

防护怎样验收，才能避免“攻击拦住了，用户也进不来”？

防御带宽与业务承载能力要分开问

分布式拒绝服务攻击（DDoS）通过大量恶意流量或请求消耗资源；常说的CC攻击通常关注应用层请求造成的消耗。选型不能把这些压力都换算成一个“防御多少G”的数字。

Gbps描述带宽量级，pps描述每秒数据包数，QPS描述每秒查询或请求数。相同请求数量，访问一张缓存图片与触发一次复杂数据库查询，对源站的压力可能差别很大。

向服务商询价时，应把问题问具体：标称能力是平台总量还是单客户可用额度？正常业务带宽、请求量和并发连接怎样限制？超出约定后是限速、追加计费，还是可能进入黑洞——即暂时丢弃目标流量？恢复条件是什么？

比“支持大流量攻击”更有用的，是一份包含防护范围、超限动作、告警方式和故障处理流程的明确说明。

把误拦截纳入测试

Web应用防火墙（WAF）用于检查和处理可疑Web请求，Bot管理则侧重识别和管理自动化访问。策略是否合适，要看具体业务，不能把“挑战更多、拦截更多”直接当作防护效果更好。

浏览器页面、App接口、支付回调、搜索抓取和WebSocket长连接，应分别检查兼容性。支付回调尤其要保留签名验证等业务鉴权，不能因为担心误拦就取消全部校验。

可以结合WAF、Bot管理与DDoS防护的协同思路，记录正常请求被哪些规则命中，再讨论适用范围与例外条件。

如需攻击模拟或压力测试，应先取得测试涉及的CDN、源站及网络服务方授权，约定强度、时间、停止条件和正常业务观察方式。没有这类测试时，可以评估方案与已有日志，但不能据此宣称已经验证其攻击承受能力。

源站入口不能留在防护之外

域名接入CDN后，历史DNS记录、未代理的子域名或其他同机服务，仍可能暴露源站IP。攻击者若能绕过CDN直连，节点上的防护不会自动覆盖这条路径。

应核查源站开放端口，按服务商提供的回源地址范围和鉴权方式限制Web入口，并为管理、监控、证书验证等必要流量保留经过确认的通道。共享回源IP允许列表并不等于只允许你自己的业务，条件允许时还应配合回源身份验证。

Cloudflare的源站保护文档也将历史IP暴露、访问限制与回源身份验证分别讨论；其中具体功能属于Cloudflare，其他服务需要确认对应实现。

主机防火墙可以拒绝不需要的请求，但如果攻击已经打满源站上游带宽，主机内的规则无法恢复这条带宽。此时还要评估上游清洗或服务器侧防护。更多入口检查可参考源站IP暴露与隐藏方法。

采购高防CDN时，怎样把需求变成可验收的方案？

先确定必须满足的条件，再比较价格，能减少试用后才发现协议不支持、动态接口不适配的问题。

CDN07的高防CDN服务将中国大陆访问优化与DDoS防护放在同一方案中，并提供节点、带宽与安全策略的定制化配置方向。对于服务器位于中国大陆以外、又需要兼顾中国大陆访问和攻击防护的网站，可以从CDN07高防CDN方案开始核对适配条件，把用户分布、源站位置和动态接口一起纳入评估。

这样的组合有助于统一讨论线路与安全策略。但具体能改善多少，仍应通过业务测试确认；节点覆盖、支持协议、套餐额度和服务约定，应落实到拟购方案中。

费用比较则要使用相同口径：正常流量或带宽、请求量、域名数量、防护额度、增值功能，以及海外源站自身的出站费用。不要只对比月费，也不要默认标注“不限”的一个项目代表其他项目都不限。可以先阅读高防CDN的收费构成，再用同一份用量清单询价。

正式切换前，先验证证书、回源Host、安全规则、真实客户端IP传递和关键业务，再按接入方案开展小范围验证。保留原配置与回退路径，预先约定出现哪些失败或性能退化就停止扩大流量。DNS变更不应被当成所有用户瞬间切换。

常见问题

海外服务器接入高防CDN后，中国大陆访问一定会变快吗？

不一定。能否改善取决于用户到节点、节点到源站的路径，以及缓存和应用处理。如果新节点对主要用户更合适，且减少了不必要的回源，就可能改善；如果慢在数据库或第三方接口，仍需处理对应瓶颈。

香港高防CDN是不是比其他地区都快？

不能这样判断。地理位置是一个条件，运营商互联、调度、拥塞和回源路径也会影响体验。优先比较自己用户所在网络与高峰时段，不要用单个城市的一次测试代表全部中国大陆用户。

高防CDN能加速登录和订单查询等动态接口吗？

可能改善网络部分的耗时，但通常不能靠共享缓存替代实时处理。需要单独测试回源与后台处理，并确认用户数据不会被错误缓存。静态图片加速明显，不等于动态接口也有同样收益。

开启CC防护后接口出错，应该直接关闭防护吗？

先查看错误响应、安全事件与源站日志，确认是否由规则误拦造成。若是兼容性问题，应针对接口、调用方和鉴权方式调整策略，并验证正常业务恢复；直接关闭全部防护可能重新暴露原有风险。

已经用了高防CDN，还需要高防服务器吗？

取决于源站暴露面、上游防护和业务协议。如果源站仍可直连、历史IP已经暴露，或者还有未经过CDN的服务，就需要另外评估这些入口。接入网站CDN，不能自动推导出整台服务器所有端口都获得保护。

游戏业务可以直接按网站的高防CDN方案购买吗？

不能只按“游戏网站”这个名称选。游戏官网、登录API、WebSocket连接与原生TCP/UDP对战流量，接入方式和要求可能不同。应提供协议、端口、客户端改造条件和延迟目标，再确定是网站CDN、SDK游戏盾还是服务器侧方案。

下一步：用自己的业务验证速度与防护

海外服务器面向中国大陆用户，选型时记住四点：

• 访问速度要看用户到节点、节点到源站两段链路。
• 静态资源、动态接口与完整业务流程应分别验收。
• 防护效果要包含正常用户可用性，以及源站是否仍能被绕过。
• 采购应同时明确测试标准、计费边界和故障后的处理方式。

准备好主要用户地区、运营商分布、源站位置、关键测试URL和已有攻击记录，就可以开展有针对性的方案比较。如果正在评估CDN07，可通过高防CDN接入咨询提交这些信息，先沟通线路、回源与安全策略，再依据约定的测试结果确定配置。