虽然卡斯滕的答案是正确的，但应该注意 Location 和 Location 指令运行after第 1 阶段 ModSecurity 规则。不过，无论如何，您的规则似乎都是第 2 阶段，因此在本例中这并不特别重要 - 尽管我无权访问规则 300016，因此无法 100% 确定这一点。
无论如何，出于这个原因，我不喜欢使用 Location 和 LocationMatch，并且个人更喜欢在 ModSecurity 中使用如下新规则进行位置过滤：
SecRule REQUEST_URI "@beginsWith /wp-(admin|login)/" \
"phase:2,id:1000,nolog,pass,ctl:ruleRemoveById=300016,\
ctl:ruleRemoveById=950117,\
ctl:ruleRemoveById=950005
...etc.
这样我就可以在规则过滤中保持一致（而不是使用上面的规则过滤第一阶段规则，并通过位置匹配过滤其他规则）。但是，每个阶段都需要一条规则。不管怎样，正如我所说，如果现在所有这些都是第二阶段或以上的规则，那并不重要。
另一个有趣的值得记住的是，如果你使用 SecRuleRemoveById 你需要指定这个after您要删除的规则，而如果您使用 ctl:ruleRemoveById 您需要指定它before您要删除的规则。
然而，大多数 WordPress 攻击都是针对这些 URL 的。所以你想成为very确保您不需要这些规则。通过转向像这样的更通用的例外，您将每条规则与超出其需要的规则进行匹配。例如，如果从您最初的设置来看，/wp-login.php 只需要其中 4 个例外，但您将把它们全部移动。
我建议您不要放松规则以匹配更多内容，而应该致力于保持规则严格并not做出这个改变。
事实上，您可以进一步收紧它们，以仅匹配导致需要异常的某些参数。例如，如果只有用户名字段引起问题，那么您可以将规则收紧：
<LocationMatch "(/wp-admin/|/wp-login.php)">
SecRuleUpdateTargetById 950117 !ARGS:'username'
SecRuleUpdateTargetById 950005 !ARGS:'username'
SecRuleUpdateTargetById 981173 !ARGS:'username'
SecRuleUpdateTargetById 960024 !ARGS:'username'
</LocationMatch>
或采用其他格式：
SecRule REQUEST_URI "@beginsWith /wp-(admin|login)/" \
"phase:2,id:1000,nolog,pass,\
ctl:ruleRemoveTargetById=950117;ARGS:username,\
ctl:ruleRemoveTargetById=950005;ARGS:username,\
ctl:ruleRemoveTargetById=981173;ARGS:username,\
ctl:ruleRemoveTargetById=960024;ARGS:username
是的，这可能意味着额外的工作，我知道您来这里是为了整合您的规则以使这变得更容易，但是如果您最终禁用了许多您想要保护的规则，那么运行像 ModSecurity 这样的 WAF 就没有什么意义了不幸的是，Wordpress 是许多坏人的活跃目标，部分原因是它的受欢迎程度。
因此，虽然我没有直接回答你的问题，但我希望这对你有用并给你带来思考。
