IIS请求含异常查询字符串，服务器性能异常排查咨询

1. 工具返回请求范围 #

• appcmd list request：默认返回当前服务器正在处理的所有活跃请求，不管请求是否存在处理异常。如果要筛选有问题的请求，需要加参数，比如appcmd list request /elapsed:1000（筛选处理时长超过1秒的请求）。
• IIS页面请求监视器（Request Monitor）：默认展示所有活跃请求，但可以通过界面的筛选器（比如“请求状态”“耗时”）过滤出存在处理问题的请求（如慢请求、出错请求），具体取决于你设置的筛选条件。

2. Rewrite Module与负载的关系 #

是的，这类异常查询字符串会和Rewrite Module相互作用，显著增加服务器负载：

• 畸形的URL（比如混合?和编码后的%3F、重复的查询参数）会让重写规则的匹配逻辑反复执行——重写模块需要解析URL结构，异常的查询字符串会导致规则多次匹配、尝试解析，消耗更多CPU资源。
• 如果你的重写规则没有针对这类畸形URL做限制，可能会触发循环重写，进一步加剧服务器资源消耗，直接导致加载时长不稳定。

3. 排查编码问题还是随机攻击的方法 #

• 分析请求来源与频率：查看IIS日志里的客户端IP，如果是少量集中IP短时间内发送大量异常请求，基本是攻击；如果IP分散、请求频率和正常用户访问一致，大概率是前端编码问题。
• 检查前端代码逻辑：核对生成目标URL的前端代码，看是否存在查询字符串拼接错误——比如把分隔参数的&误写为?，或者没有对特殊字符做正确URL编码，导致生成畸形查询字符串。
• 模拟测试对比：
  • 模拟正常编码的请求，观察服务器处理耗时；
  • 手动发送异常URL请求，对比两者的处理耗时和服务器资源占用情况。如果异常请求耗时明显更长，且资源占用飙升，说明这类请求是性能问题的诱因。
• 查看请求返回状态：攻击类请求通常会返回400（无效请求）、404（资源不存在）或500（服务器错误）；如果是编码问题，请求可能返回200，但处理过程中因为解析异常导致耗时增加。

内容的提问来源于stack exchange，提问作者buck1112