我来帮你搞定这个困扰——我之前在测试WebService授权状态时也碰到过类似的情况，SoapUI的缓存和层级配置很容易踩坑。下面是针对性的解决步骤：

1. 检查层级授权配置，确保全局/项目级设置不覆盖单个请求 #

SoapUI的授权设置有层级（全局→项目→请求），低层级的设置会被高层级覆盖：

• 右键点击项目根节点，选择Show Project View，切换到Authorization标签页
• 这里如果配置了任何授权类型（比如Basic Auth），哪怕单个请求选了No Authorization，项目级的设置还是会生效。把这里也改成No Authorization，点击Save后重启SoapUI
• 回到单个请求的Authorization标签，确认选了No Authorization，一定要点击Apply按钮（很多人会忽略这步，导致设置没生效）

2. 清理请求的Raw头缓存 #

SoapUI有时候会缓存旧的请求头，哪怕你改了授权设置：

• 打开请求的Raw标签页，手动删除掉Authorization: xxx那一行
• 点击请求顶部的Save按钮，然后关闭并重新打开请求，或者直接重启SoapUI
• 也可以新建一个完全干净的请求，不配置任何授权，测试是否还会自动添加Authorization头，排除旧请求的缓存问题

3. 排查自动添加头的脚本 #

如果你的项目里有Groovy脚本，可能会自动往请求里注入授权头：

• 打开单个请求的Script标签页，查看Before Request脚本块，检查是否有类似testRequest.setRequestHeader("Authorization", "Bearer xxx")或者Basic Auth编码的代码，如果有，注释或删除这部分
• 再检查项目根节点的Scripts标签页，看看有没有全局的前置脚本在自动添加授权头

另外，你提到的临时验证方案确实是个实用的小技巧：通过发送正确/错误凭据来反向验证服务的授权状态——如果服务未开启授权，错误凭据也能通过；如果开启了授权，错误凭据会被拒绝。这个方法可以帮你绕过SoapUI的配置问题，先完成测试验证。

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