拦截页面要说明什么
拦截页面是用户请求被 WAF 拦下时看到的界面。它要完成两件事：告诉用户这不是网站故障而是安全策略拦截，并给出事件编号与联系方式，让客服与安全团队能快速定位到具体请求。设计时注意不暴露规则编号与内部信息，避免给攻击者提供试探依据，面向多地区业务还要准备多语言版本。
基本信息
| 页面内容 | 拦截原因摘要、事件编号、客服联系方式 |
|---|---|
| 注意 | 不暴露规则编号、内部地址等敏感信息 |
| 多语言 | 面向多地区业务需准备对应语言版本 |
| 编号作用 | 事件编号要能对应日志中的具体请求 |
典型使用场景
- 站点上线：配置自定义拦截页面，避免使用厂商默认页
- 用户投诉处理：凭事件编号快速定位被拦请求
- 多地区业务：准备对应语言的提示与联系方式
- 误拦截优化：统计拦截页面来源，辅助分析误报
- 合规说明：向用户解释拦截依据，减少争议
提示要素示例
提示要素示例
您的请求被安全策略拦截
事件编号：REQ-20261012-0001
如为正常访问，请联系 support@example.com 并提供上述编号
# 要点：说明原因摘要、给出事件编号、提供联系方式
# 避免：显示规则编号、内部地址、设备型号等信息
# 编号规则：与日志中的请求标识保持一致，便于检索定位要素与作用
| 要素 | 作用 | 注意 |
|---|---|---|
| 原因摘要 | 让用户理解不是网站故障 | 不写具体规则细节 |
| 事件编号 | 客服定位具体请求 | 与日志标识保持一致 |
| 联系方式 | 提供申诉与反馈渠道 | 保持可用，避免无人响应 |
| 语言版本 | 服务多地区用户 | 按业务覆盖地区准备 |
拦截页面要把事件编号同时写入日志：客服拿到编号就能查到请求详情，比让用户描述页面内容高效得多。