默认防护和自动切换不是装饰。机器回调过不了 5 秒盾/验证码，必须按路径放行。
防护的目标是挡 CC、扫描、空 UA、异常方法、恶意指纹，不是把你的支付回调和监控探针一起打死。
------------------------------------------------
一、先分清开关语义
------------------------------------------------
1. 默认防护：域名保存后即按选定模式执行（浏览器挑战、CC 阈值、基础过滤等，视模式而定）。
2. 自动切换：根据负载/攻击态势在模式间升级或回落，不是“每次访问都换皮肤”。
3. 两者都关：不应主动给正常用户套盾；仅在命中明确安全策略或全局规则时拦截。
4. 你手动测一种盾，只代表该模式被触发，不代表用户默认也会吃到。
若担心影响体验：生产站先关自动切换，默认模式用宽松/普通，观察拦截日志再收紧。
------------------------------------------------
二、为什么“人能开站，支付没到账”
------------------------------------------------
支付异步通知、微信/支付宝回调、短信钩子、服务器监控、程序安装器拉 CSS/API：
它们不是完整浏览器环境，过不了 5 秒盾、滑块、JS 挑战。
表现：
- 回调 URL 在拦截日志里反复出现
- 支付成功但订单未更新
- App API 大面积 403/挑战页 HTML
------------------------------------------------
三、正确治理
------------------------------------------------
1. 对回调路径做精确放行（白名单路径），例如 /notify /pay/callback /api/webhook
2. 不要用“全站关防护”偷懒，除非临时排障。
3. 管理后台、安装器、编辑器静态资源若被误伤，按路径或 UA 精细放行，而不是永久关盾。
4. 自定义规则先“记录/观察”，确认无误伤再“拦截”。
------------------------------------------------
四、误拦截排查顺序
------------------------------------------------
1. 看拦截日志：命中的是 5 秒盾、点击、滑块、CC、空 UA、异常方法，还是自定义规则。
2. 复现请求是否带浏览器完整头；curl 默认 UA 被空/异常策略打到很正常。
3. 检查是否刚开启严格模式或自动切换抬升。
4. 对必要路径加白后，用服务端模拟回调验证。
------------------------------------------------
五、建议基线
------------------------------------------------
- 内容站/企业站：普通防护 + 静态缓存
- 登录/支付密集：普通防护 + 回调路径放行 + 后台单独限制
- 被打时：再开自动切换或临时严格，攻击停后降级，避免长期严模式伤转化率
防护规则是生产配置，不是演示按钮。改模式后看日志 10–30 分钟再定论。