同一套SaaS平台，有的客户登录正常，有的公司整层办公室都被限流；静态页面很快，实时通知却频繁断线；开启缓存后，还要担心不同租户看到彼此的数据。

对SaaS而言，“网站能打开”只是接入测试的起点。

选择SaaS高防CDN，应优先验证多租户数据隔离、登录与接口兼容性、长连接稳定性，再比较线路、防护容量和费用。

租户数据串用、身份流程被打断、持续连接不稳定，任何一项都可能让首页测速的优势失去意义。

SaaS选高防CDN，为什么不能照搬普通网站的标准？

多租户是指多个企业或组织共同使用一套平台，各自拥有账号、数据和权限。它们可能共用服务器、数据库和访问入口，但业务边界必须清楚。

这使得SaaS的选型对象不只是一个域名，而是一组相互关联的入口：主站、租户子域名、客户自定义域名、登录、接口、文件下载以及实时连接。

例如，十个租户共用一个出口IP，并不代表它们是同一个用户；一个租户短时间导出大量报表，也不应该自动消耗掉整个平台的接口容量。CDN配置需要与应用的身份、配额和资源管理配合。

多租户场景，先确认缓存会不会跨边界复用

域名、路径和请求头，分别怎样影响内容？

常见的租户访问方式包括：

• 子域名：tenant-a.example.com与tenant-b.example.com。
• 路径：example.com/tenant-a/与example.com/tenant-b/。
• 共享API：请求路径相同，通过会话或令牌确定租户。
• 自定义域名：每个客户使用自己的品牌域名。

CDN通常使用“缓存键”区分缓存对象，可以把它理解为判断两次请求是否能共用内容的标识。选型时，要确认实际规则是否保留了影响内容的域名、路径和参数，尤其注意自定义缓存键、忽略查询参数和路径改写。

例如，两家企业访问相同的/api/report路径，但返回各自的经营报表。如果只按路径缓存，就可能错误复用响应。即使缓存键包含租户标识，同一租户内的管理员与普通员工也未必拥有相同的数据权限。

缓存分开存放，不等于请求已经通过权限检查。

对于需要登录、涉及用户权限的敏感响应，起步方案应优先避免共享缓存；确有缓存需求时，再设计可信的身份校验、隔离维度和失效机制。

OWASP在多租户安全指南中强调，客户端提交的租户标识只能用于选择目标，服务端仍需验证当前身份是否有权访问该租户。不能因为请求携带了X-Tenant-ID，就信任它拥有对应权限。

有Cookie或Set-Cookie，不代表一定不会被缓存

一个常见误解是：“接口带登录Cookie，CDN自然不会缓存。”不同产品、规则和覆盖配置可能产生不同结果，不能把默认行为当成安全边界。

IETF的HTTP缓存标准RFC 9111明确指出，Set-Cookie本身不会阻止缓存。控制响应存储需要正确的缓存指令，同时核对CDN是否存在强制缓存等覆盖规则。

对于不应保存的敏感响应，可以由应用返回如下响应头，并在接入后验证实际行为：

Cache-Control: no-store

这是HTTP响应头示例，不是终端命令，也不是所有接口都应统一套用的配置。公开帮助文档、版本化脚本和图片，可以根据内容属性采用其他缓存策略。

测试至少要覆盖两个租户、同一租户的不同角色以及未登录访问。使用隔离的浏览器会话，依次访问相同业务路径，并验证响应中的数据归属。退出登录、成员移除或权限降低后，也应确认不能继续拿到此前有权限的数据。

可以先由租户A请求，再由租户B访问对应地址，随后反向重复，并覆盖缓存命中与回源两种情况。测试内容应使用各租户独有、可辨认的标记，避免因为示例数据相同而漏掉错误复用。

自定义域名还要考虑接入与退出

面向企业客户的SaaS，域名管理往往是持续工作。新增客户、证书续期、域名解绑和客户流失，都需要相应流程。

采购时应核对：能接入多少自定义域名，如何验证域名归属，证书如何管理，规则能否批量应用，以及解绑后怎样清理域名与租户映射。泛域名证书也不能代替对任意客户独立域名的覆盖。

这些能力不能从“支持多个域名”直接推导。平台规模较大时，人工逐个配置的时间也应计入运维成本。

登录防护怎么做，才能避免整家公司被一起拦截？

单IP限速需要考虑企业共享出口

企业办公室、校园和移动网络可能让许多正常用户共用公网出口。若只设置简单的单IP阈值，早晨集中登录、批量刷新页面或客户端同步，就可能触发误拦截。

另一方面，分布式撞库可能把请求分散到大量IP。单个来源看起来频率不高，账号仍在持续承受密码尝试。

OWASP在身份认证安全指南中建议将失败计数与账号关联，并提醒账号锁定机制本身也可能被利用来阻断正常用户。选型时应同时考虑来源、账号和业务行为，而不是只提高或降低一个IP阈值。

可以把职责分开：CDN处理入口异常流量和能够识别的请求特征；应用负责账号状态、身份验证、租户权限及需要可信身份的配额。CDN是否支持相应维度的规则，需要按具体方案验证，不能默认它已经理解你的租户和账号体系。

登录页、登录提交和身份回调，要分别测试

SaaS登录流程可能涉及单点登录（SSO）、多因素认证、身份提供方跳转、回调以及令牌刷新。登录页面打开正常，只验证了其中一个环节。

至少应整理以下路径：

不应对所有机器接口强制使用浏览器验证。API期待JSON，收到的却是HTML挑战页，即使状态码为200，客户端也可能报错。反过来，为了让回调成功而关闭整站防护，也会扩大暴露范围。

对于接口分类和规则配合，可以结合API接口频繁被刷时的防护思路，将登录、查询、导出和第三方调用分开处理；不同安全机制的职责，则可参考WAF、Bot管理与DDoS防护如何协同。

WebSocket和SSE，要测哪些长连接能力？

先分清连接类型，再问限制

实时通知、在线协作和AI生成结果，可能使用WebSocket，也可能使用SSE，二者不能互相替代。

WebSocket适合持续双向通信。按照WebSocket协议RFC 6455，连接建立之后还有后续数据交换，因此只测握手远远不够。

SSE是服务端通过HTTP持续向客户端发送事件。MDN在SSE使用文档中说明，事件流使用text/event-stream类型，并以空行分隔消息。接入后需要确认这些消息会逐步到达，而不是积攒到最后一次性返回。

一个产品支持WebSocket，不能据此认定SSE或其他流式协议也按业务预期工作。连接空闲超时与连接总时长上限也应分开询问，心跳不一定能解决所有断开问题。

测试SSE是否逐步输出

在安装了curl的Linux或macOS终端，可以用下面的命令检查自己的测试事件流。将示例地址替换为实际SSE接口；需要鉴权的接口应使用专用测试会话，不要为了测试而开放生产接口。

curl -N -sS --connect-timeout 5 --max-time 30 \
  -H 'Accept: text/event-stream' \
  -D - \
  'https://example.com/events'

根据curl官方手册，-N关闭的是curl自身的输出缓冲，不会关闭CDN、网关或源站中的缓冲；--max-time 30将测试总时长限制为30秒。

观察响应类型、事件内容以及到达节奏。测试源站若已按固定节奏发送事件，客户端却成批收到，应结合源站发送日志与客户端接收时间排查各层缓冲，不能仅凭现象认定一定是CDN问题。

401或403可能来自未登录或访问策略，需先解决测试身份。命令在30秒时主动结束并报告超时，也不等于服务故障。这只是短时连通与输出检查，正式验收还要覆盖业务实际需要的持续时长、空闲期和断网恢复。

连接恢复时，别把压力全部推向登录服务

节点切换、客户端网络变化或服务发布后，大量连接可能在短时间内重新建立。如果每条连接都同时刷新令牌、查询权限并重新订阅，鉴权和订阅服务可能成为新的瓶颈。

应测试客户端退避与随机延迟、重新鉴权、订阅恢复，以及消息去重和必要的续传机制。SSE客户端能够自动重连，并不代表应用天然具备事件补发能力；WebSocket重连也不等于会话状态自动恢复。

此外，长连接建立后的租户、频道和消息权限仍需由应用执行。选型时要分清CDN检查的是握手请求，还是还提供连接内的消息检测，避免把两者当成同一项能力。

一个租户被攻击，其他租户能否继续正常使用？

多租户可用性不仅取决于CDN。某个租户的大量请求可能消耗共享的应用线程、数据库连接、导出队列或文件处理资源。

因此，需要同时评估两层能力：入口处是否可以缩小异常流量的影响范围；应用侧是否对租户的并发、任务和资源使用设置合理边界。

按租户限流所依据的身份必须可信。不能让客户端随意修改一个请求头，就绕过限额或把消耗记到其他租户名下。登录前尚无可信租户身份的请求，也需要独立的入口保护策略。

运维侧不要只看全平台平均值。至少应能把受影响的域名、路径、规则、时间段与应用记录关联起来，再判断问题来自CDN拦截、回源失败还是应用处理。租户维度可以由可信的应用日志补齐，不必假定每家CDN都直接提供。

记录日志时，避免直接保存密码、完整令牌或敏感业务正文。对用于关联的请求标识和租户标识，也应有明确的来源与访问权限。

费用与线路，应该怎样放进SaaS选型表？

SaaS的小响应接口未必消耗很多带宽，但可能有很高的请求频率；实时协作平台可能流量不大，却长期保持大量连接。按月流量估算全部成本，容易漏掉重要项目。

询价时应分别列出域名数量、月流量、峰值请求量、并发连接、新建连接速率、日志需求和必要安全功能，并确认这些项目是否计费、如何计量及是否已包含。

大客户自定义域名增长、日志保留周期延长，以及一次集中重连，都可能改变资源需求。具体核算可结合高防CDN套餐、正常流量与额外费用计算，用正常月份和业务高峰分别估算。

线路测试也要按业务拆开：静态资源关注分发，登录与查询关注动态回源，实时业务关注持续传输及恢复。海外部署且主要服务大陆企业客户时，可以参考海外源站访问中国大陆的速度与防护指南，覆盖主要地区、运营商和工作时段。

筛选服务时，可以将CDN07高防CDN方案纳入测试：其服务结合内容分发与DDoS防护，支持WebSocket，并提供节点、带宽和安全策略的定制方向。对SaaS团队而言，这些是进一步讨论业务适配的基础；租户缓存规则、SSO兼容性、SSE行为及配额管理仍应逐项验证，不能从产品名称直接推导。

试用验收：哪些项目应该优先通过？

建议在授权测试环境中准备两个租户、不同角色账号和真实客户端，先验证正确性，再评估性能与防护。不要在生产环境自行模拟撞库或进行未经约定的压力测试。

租户隔离失败、核心身份流程无法完成，或业务必需的持续通信不兼容，应先解决再扩大接入。防御数字更高、静态测速更快，都不能抵消这些问题。

常见问题

SaaS平台接入CDN后，会不会出现租户数据串用？

错误的共享缓存或权限配置可能造成这种风险，但不是接入CDN的必然结果。应区分公开、租户级和用户级内容，并测试缓存命中、退出登录和权限变化后的行为。

每个租户都有独立子域名，就足够隔离了吗？

不够。还要核对缓存键、回源映射、应用授权及数据访问。自定义规则若把不同域名合并处理，或者应用未校验租户权限，仍可能越界。

公司员工一起登录被限流，是防护太强吗？

可能是规则没有适配共享出口和集中登录行为，也可能存在其他原因。应结合命中规则、账号行为及应用日志判断，不能只把IP阈值调高或完全关闭防护。

高防CDN支持WebSocket，就一定支持SSE吗？

不能直接推导。SSE需要单独验证持续HTTP响应、缓冲、缓存和超时行为；WebSocket则要验证连接及消息处理。两类业务应分别列入验收。

SSE等到最后才一次性输出，是CDN缓存了吗？

不一定。应用、反向代理、压缩处理、CDN或客户端都可能影响输出节奏。应对照各层发送与接收记录，逐段排查缓冲和刷新行为。

高防CDN能替代SaaS的账号与租户权限系统吗？

不能。CDN可以承担相应的入口防护，但账号状态、租户成员关系、对象权限和业务配额仍需要可信的应用逻辑执行。

把真实业务流程带进选型测试

SaaS高防CDN选型可以抓住四件事：

• 缓存命中以后，租户和用户权限仍然正确。
• 登录、SSO与机器接口在防护开启后仍能完成。
• 长连接不仅能建立，还能持续通信并合理恢复。
• 单租户异常、故障排查与费用增长都有可管理的范围。

下一步可以整理租户访问方式、域名规模、登录链路、长连接类型、峰值用量及主要用户地区，选取一组具有代表性的租户进行验证。

如果准备测试CDN07，可通过高防CDN接入与方案咨询提交这些需求，将必须满足的条件写入测试清单。用租户隔离、登录成功和持续通信的结果判断适配程度，比只比较防御带宽更接近SaaS真正需要的可用性。