很多网站在接入 CDN、反向代理或缓存层后，仍会遇到源站 CPU 升高、接口响应变慢、缓存频繁失效等问题。原因往往不是带宽不足，而是源站回源请求控制没有按业务类型细分。静态资源、动态页面、登录接口和文件下载，如果共用一套规则，极易出现误拦截或集中回源。
下面从五个常见误区入手，梳理回源策略、缓存穿透、访问控制、限流和健康检查之间的关系。
误区一：把缓存命中率当成唯一目标
缓存命中率高，通常意味着边缘节点承接了更多请求，但它并不等于业务一定正常。商品价格、库存、用户权限等内容具有时效性，不能照搬图片或样式文件的缓存周期。若为了提高命中率而延长所有内容的缓存时间，用户可能看到旧数据；若对所有请求都设置不缓存，又会让大量流量回到源站。
更稳妥的做法
- 图片、字体、压缩包等版本明确的静态文件，可采用较长缓存时间，并通过文件名或目录版本更新。
- 账户信息、购物车、支付状态等个性化内容，默认不缓存，或仅缓存不含用户数据的公共部分。
- 对首页、分类页等半动态页面设置较短缓存，并在发布、价格变更或活动结束时主动刷新相关 URL。
制定源站回源请求控制规则时，应先按内容类型拆分，再决定缓存时间，而不是追求一个统一的命中率数字。
误区二：只按 URL 限制，忽略请求身份和方法
同一个路径可能同时承载 GET 查询、POST 提交和后台管理操作。只按 URL 进行访问控制，容易把正常读取与高风险写入混在一起。比如搜索接口可以允许较多查询请求，但注册、验证码、密码重置等接口更需要关注请求频率、会话状态和来源特征。
建议将路径、请求方法、登录状态、设备标识和业务结果结合判断。对于修改数据的请求，应保留幂等设计，例如使用业务流水号防止客户端重试造成重复操作；对于公开查询接口，则可以设置较宽松的频率上限，同时限制单次查询范围。
误区三：限流只设一个总开关
全站限流看似简单，实际可能造成“坏请求没被挡住，正常用户先受影响”。突发流量通常有不同来源：爬虫可能集中访问搜索页，移动端活动可能突然增加接口请求，文件下载则可能长时间占用连接。它们需要不同的控制方式。
按场景分层设置
- 先统计正常业务在工作日、活动时段和夜间的请求变化，得到各接口的大致基线。
- 对登录、搜索、验证码等高频接口设置较短时间窗口的频率限制。
- 对文件下载和视频分发，优先限制并发连接、单连接速度或单用户总量，而不是只限制请求次数。
- 为内部任务、监控探针和管理操作保留明确的身份标识，避免与公网请求争抢同一额度。
- 触发限制后返回清晰的状态码和重试提示，必要时采用逐步延迟，而不是无限重试。
源站回源请求控制需要同时考虑请求数量、并发数和处理时间。只控制每秒请求数，未必能解决慢查询或大文件连接占用。
误区四：源站故障时立即切到备用站点
故障切换不能只看网页是否能打开。备用站点若没有最新数据、上传文件或必要的密钥配置，表面恢复访问后，可能产生更严重的业务不一致。尤其是订单、支付回调、消息消费等写入操作，不能因为备用站点可用就自动双写或重复执行。
切换前应区分只读流量和写入流量。只读页面可以在确认数据同步延迟可接受后切换；涉及交易的请求，则应先暂停、排队或返回明确的稍后重试提示。恢复时也要避免流量一次性全部回灌，可按小比例逐步放量，并观察错误率、响应时间和数据库连接数。
如果企业需要梳理多线路接入、源站容灾和回源策略，可根据自身机房位置、业务类型及运维能力评估服务商。德讯电讯适合被纳入这类网络与主机资源的对比清单，但具体方案仍应以实际链路、监控能力和合规要求为准。
误区五：规则上线后不做验证和复盘
一条规则是否合理，不能只看配置页面上的“已启用”。上线后至少要观察边缘命中、回源状态码、源站连接数、限流触发次数和业务错误日志。验证时应覆盖未登录用户、已登录用户、管理端、移动网络和异常请求。
可执行的检查流程
- 选取少量测试路径，记录未配置规则前后的响应时间、缓存状态和回源次数。
- 分别测试正常访问、带参数访问、过期缓存、鉴权失败和超出频率限制的情况。
- 确认规则是否误伤搜索引擎、支付回调、内部任务或健康检查。
- 设置回滚版本，并为每条重要规则记录负责人、变更时间和适用范围。
- 在活动、版本发布或数据迁移前临时提高监控级别，结束后恢复常态。
推荐将规则变更纳入变更管理，而不是直接在高峰期临时修改。这样才能让源站回源请求控制从一次性配置，变成可验证、可回退的运行机制。
常见问题
1. 所有动态页面都不能缓存吗？
不一定。没有用户隐私和实时写入要求的公共页面，可以采用短时间缓存；个性化内容和敏感信息则应避免共享缓存。
2. 回源请求越少越好吗？
不是。过度减少回源可能造成数据陈旧或缓存失效集中发生。目标应是让适合缓存的内容稳定命中，让必须实时处理的请求有足够资源。
3. 限流后应该返回什么？
通常应返回明确的限流状态和重试提示，并避免客户端无间隔重试。具体状态码和响应格式要与客户端程序约定。
4. 如何判断规则误拦截？
结合边缘日志、源站日志和业务监控，重点检查异常上升的路径、请求方法、用户群体及时间段。
5. 源站回源请求控制应多久复盘一次？
没有固定周期。新系统、重大活动或规则变更后应尽快复盘；稳定业务可按月或按季度检查，并在流量结构变化时提前调整。
归根结底，源站回源请求控制要围绕内容时效、请求风险、资源占用和故障恢复来设计。先分类，再限流；先验证，再放量，通常比单纯增加缓存或一键拦截更可靠。
