部署加速服务后，最容易出现的问题不是节点不够多，而是同一项工作被两端重复处理：边缘节点缓存页面，源站又设置了另一套缓存；边缘节点改写跳转，应用也执行重定向。梳理海外服务器与边缘节点如何分工，应从每种请求路径的处理方式入手，而不是笼统地把流量都交给某一端。
先按请求路径划分职责
边缘节点通常位于用户与源站之间，负责就近接收请求、执行明确配置的转发或缓存规则；海外服务器作为源站，运行应用并提供最终内容。前者优化传输路径，后者负责业务结果。边缘节点可以处理部分安全和协议工作，但不应默认复制完整应用逻辑。
| 请求类型 | 边缘节点职责 | 海外源站职责 |
|---|---|---|
| 图片、字体、版本化脚本等静态文件 | 按缓存规则保存副本，处理压缩或条件请求 | 保存原始文件，提供更新后的版本 |
| 商品页、账户页等动态页面 | 默认转发；只有确认内容可共享时才缓存 | 执行应用逻辑，返回与用户状态对应的内容 |
| 登录、支付及业务 API | 传递请求头、查询参数和响应状态，不缓存个性化结果 | 执行身份验证、权限判断和数据操作 |
例如，/assets/app.版本号.js这类带版本标识的资源，适合设定较长缓存；/account、/login以及带授权信息的 API，一般应绕过共享缓存。具体规则要结合响应头和业务要求确认，不能只凭扩展名判断。
哪些工作放在边缘，哪些留给源站
边缘侧：减少重复传输，但规则要可解释
边缘可承担静态资源缓存、TLS 连接接入、基础请求过滤及到源站的反向代理。应逐条确认缓存键是否包含必要的查询参数、Cookie 或语言信息；忽略这些差异，可能把一个用户的内容返回给另一个用户。登录态、授权响应和明确标记为不可缓存的内容，应设置绕过规则。
源站侧：保留业务权威和数据一致性
应用状态、权限判断、订单处理和数据读写应由源站应用负责。若源站也配置页面缓存，需要明确它服务的是边缘节点回源，还是直接访问者，避免两层缓存期限叠加后难以解释内容为何未更新。条件允许时，可限制源站只接受边缘节点的回源流量；同时正确配置可信代理来源，不能无条件信任客户端提交的转发地址。
上线前按顺序验证，减少职责冲突
- 列出路径清单：至少区分静态文件、公开页面、登录页面和 API，记录各路径是否带用户状态。
- 指定唯一规则负责人：为每类路径写明由哪一端决定缓存、跳转、压缩和访问限制；需要两端配合时，注明执行顺序。
- 先设保守缓存：动态页面与接口先转发不缓存，再对确认可共享的资源逐项启用缓存，并核对源站的 Cache-Control 等响应头。
- 分别测试命中与回源：检查响应状态、缓存状态标记、关键响应头和内容差异；用带登录状态与不带登录状态的请求确认没有串用结果。
- 准备绕行和回滚：确认如何临时关闭边缘缓存或将流量直达源站，并监控回源错误、响应延迟和应用日志，确保异常能定位到具体一层。
观察数据时不要只看页面是否打开。若边缘返回旧内容，先核对缓存键、有效期和失效规则；若请求到达源站却被拒绝，再检查来源限制与代理头配置。日志中保留请求路径、状态码、边缘处理结果和回源状态，能帮助区分缓存问题与应用故障。
常见问题
边缘节点能否运行应用逻辑？
部分平台支持边缘计算，但是否适用取决于运行环境、状态存储和部署方式。涉及核心数据与权限的逻辑，通常应保留在源站，避免边缘副本与主应用行为不一致。
所有静态文件都适合长时间缓存吗？
不适合。带内容版本号的文件较容易长期缓存；固定文件名但会原地更新的资源，应使用较短有效期或可靠的失效机制。
出现页面内容不一致，先查哪一端？
先判断请求是否命中边缘缓存，再对比边缘响应与源站响应；随后核对响应头、缓存键和失效记录。这样能较快判断问题在边缘规则还是源站生成内容。
把路径、处理动作和责任端写成可检查的规则，部署后的职责就不必依靠口头约定。落地海外服务器与边缘节点如何分工时，核心是让边缘负责明确的传输与缓存任务，让源站继续作为业务内容和数据的权威来源。