Web服务器本身不直接提供协议层攻击识别过滤策略，该能力主要由WAF承担；但可通过Nginx/Apache配置实现基础协议合规校验，如限制请求头大小、拒绝非法方法、拦截路径遍历等，再配合专业WAF深度解析完成完整防护。
Web 服务器本身不直接提供“协议层攻击识别过滤策略”的完整能力，这类防护通常由 Web 应用防火墙（WAF）承担。但你可以通过配置 Web 服务器（如 Nginx、Apache）配合 WAF 或启用内置安全机制，实现对协议层异常行为的初步识别与拦截。关键在于理解协议层攻击特征，并在合适位置部署过滤逻辑。
明确协议层攻击的典型表现
协议层攻击不依赖业务逻辑漏洞，而是利用 HTTP/HTTPS 协议规范的边界绕过或滥用，常见类型包括： - 请求头畸形：如超长 Host、重复 Content-Length、非法 Transfer-Encoding、空 User-Agent 或恶意构造的 Accept 头 - 请求体异常：超大 POST 数据、分块编码（chunked）格式错误、不匹配的 Content-Length 与实际长度 - 方法/路径违规：非法 HTTP 方法（如 PROPFIND、DEBUG）、URL 中含控制字符（%00、%0A）、路径遍历符号（../）出现在非静态资源路径 - 状态码滥用：服务端返回敏感信息的错误页（如 404 显示绝对路径、500 泄露堆栈）这些行为本身未必触发 SQL 注入或 XSS，但常是扫描器探路或为后续攻击铺垫，WAF 的协议层过滤正是针对此类“不合规范”的流量做第一道筛查。
在 Web 服务器侧做基础协议合规校验
Nginx 和 Apache 可通过配置限制明显违规请求，减轻后端压力：Nginx 示例（防止常见协议滥用）：
- 限制请求头大小：
large_client_header_buffers 4 8k;（避免超长 Host 或 Referer） - 拒绝非法方法：
if ($request_method !~ ^(GET|HEAD|POST|PUT|DELETE|OPTIONS|PATCH)$) { return 405; } - 拦截路径遍历：
if ($request_uri ~ "\.\./") { return 403; }（注意：不能替代 WAF 的深度解码检测） - 关闭危险方法（如 TRACE）：
if ($request_method = TRACE) { return 405; }
Apache 示例（启用 mod_security 基础协议检查）：
- 安装后默认启用部分协议规则，例如拦截空 User-Agent：
SecRule REQUEST_HEADERS:User-Agent "^$" "id:1001,deny,msg:'Empty User-Agent'" - 限制请求体大小：
SecRequestBodyLimit 10485760（10MB），超限返回 403 - 拒绝不支持的编码：
SecRule REQUEST_HEADERS:Transfer-Encoding "!@rx ^(chunked|identity)?$" "id:1002,deny,msg:'Invalid Transfer-Encoding'"
将协议层过滤交由专业 WAF 承担
Web 服务器的配置只能覆盖简单场景，真正可靠的协议层防护需依赖 WAF 的深度解析能力。主流云 WAF（如华为云 WAF、阿里云 WAF）默认开启协议层过滤，无需额外开启，但需确认：- 防护策略中“Web 基础防护”已开启，且“常规检测”处于启用状态——它包含协议合规性校验（如畸形头、非法方法、超大请求体）
- 不要关闭“协议层过滤”开关（部分 WAF 控制台会单独列出该选项，名称可能为“HTTP 协议合规检测”或“畸形请求拦截”）
- 若业务使用 CDN 或高防，确保 WAF 部署在真实客户端 IP 可见的位置，否则源 IP 丢失会影响基于 IP 的协议异常统计
验证协议层防护是否生效
配置完成后，可用简单测试验证基础拦截能力：- 发送超长 Host 头：
curl -H "Host: a...[10000个a]..." http://your-site.com→ 应返回 400 或被 WAF 拦截页 - 构造非法 Transfer-Encoding：
curl -H "Transfer-Encoding: badstuff" http://your-site.com→ 应被拒绝 - 尝试 TRACE 方法：
curl -X TRACE http://your-site.com→ 应返回 405（服务器侧）或 403（WAF 侧）
不复杂但容易忽略
