把请求引向交付节点
CDN可以通过DNS安排或HTTP重定向等方式，把请求引向选定的交付节点。选择还要考虑节点覆盖范围和能力，而不是简单把所有用户固定送到一个地址。
RFC 7336讨论CDN互联时的委派与请求导向，RFC 8008进一步说明覆盖范围和能力如何参与选择。这些是协作接口，不要求所有CDN必须采用完全相同的内部结构。
缓存命中与回源
如果节点保存了可以复用的内容，就可能直接响应；缓存缺失时则需要向上游或源站取得内容。多层CDN还可能沿委派路径继续请求，并不是每次都直接联系最初发布者。
HTTP缓存依据新鲜度与验证规则判断是否能复用响应。内容在某处已经更新，不会凭空改写所有副本；过期判断、验证和必要的失效处理共同决定用户看到哪一版。
同一个URL也可能有不同响应版本。若源站按Accept-Language选择语言，并用Vary: Accept-Language说明这种变化，共享缓存复用已存响应时还须核对相应请求字段，而不能只匹配URL。缺少匹配版本时，需要验证或向上游取得合适响应；Vary中的星号则总不能作为普通匹配命中。这个机制只处理响应选择的维度，不会把用户专有内容自动变成允许公开共享的内容。
交付能力与内容边界
CDN并不只需要“把文件复制出去”。共享缓存能否保存和复用某个响应，还要遵守缓存控制、认证和请求匹配等语义，用户专有内容不能仅因访问频繁就被随意共享。
节点靠近用户可以减少某些网络等待，却不能保证源站计算、首次内容取得或应用程序本身都很快。评估一次慢请求，需要区分节点命中、回源路径与源站处理。