看起来你在Plesk搭配IIS的环境里发送PUT请求时碰到了401未授权错误，结合你给出的web.config片段，我整理了几个最可能的解决方向，你可以逐一排查：

1. 让IIS允许PUT方法通过请求筛选 #

默认情况下，IIS的请求筛选机制可能会拦截PUT这类用于修改资源的HTTP方法。你需要在web.config的<system.webServer>节点下添加配置，明确放行PUT：

<system.webServer>
  <!-- 保留你已有的validation、modules等配置 -->
  <security>
    <requestFiltering>
      <verbs allowUnlisted="false">
        <add verb="GET" allowed="true" />
        <add verb="POST" allowed="true" />
        <add verb="PUT" allowed="true" />
        <!-- 要是需要DELETE方法也可以加上 -->
      </verbs>
    </requestFiltering>
  </security>
</system.webServer>

如果觉得列出所有允许的方法太麻烦，也可以把allowUnlisted设为true，但明确列出的方式更安全，能避免不必要的方法被放行。

2. 检查Plesk里的网站权限配置 #

Plesk的权限设置很容易被忽略，你需要确认这两点：

• 登录Plesk面板，进入网站与域名 -> 你的目标网站 -> 主机设置，确保勾选了允许修改、创建和删除文件——PUT请求通常需要修改服务器上的资源，这个权限是基础。
• 同样在网站的Web应用程序选项里，检查应用程序池的运行身份（比如ApplicationPoolIdentity）是否对PUT目标目录有写入权限。如果用的是匿名身份验证，IUSR用户也需要对应目录的写入权限。

3. 配置正确的IIS身份验证规则 #

如果你的PUT请求需要身份验证，得确保对应的验证方式已经启用：

• 在Plesk的网站与域名 -> 你的网站 -> IIS设置 -> 身份验证里，启用你需要的验证类型（比如基本身份验证、Windows身份验证），并且请求时要携带有效的凭证。
• 要是允许匿名访问PUT接口，一定要确认匿名身份验证是开启状态，并且匿名用户有足够的权限。

4. 排查HTTP模块是否干扰PUT请求 #

你当前的web.config里配置了ApplicationInsightsWebTracking模块，虽然它一般不会拦截PUT请求，但可以临时注释掉这个模块配置，测试一下PUT请求是否恢复正常：

<!-- 临时注释掉，测试用 -->
<!--<httpModules>
  <add name="ApplicationInsightsWebTracking" type="Microsoft.ApplicationInsights.Web.ApplicationInsightsHttpModule, Microsoft.AI.Web" />
</httpModules>-->

如果注释后请求正常，那大概率是这个模块的配置或版本有问题，你可以尝试更新Application Insights的NuGet包，或者调整它的跟踪规则。

记得每调整完一项配置后，都要重新发送PUT请求测试效果，这样能快速定位到问题所在。

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