我之前也遇到过几乎一模一样的场景——混合Windows认证和匿名访问的SignalR应用，折腾了好一阵才搞定，给你分享下关键的解决步骤：

1. 给SignalR Hub添加匿名访问权限 #

这是很多人容易忽略的核心点：就算你在web.config里开了路径匿名，SignalR的Hub本身如果没有允许匿名，还是会触发认证拦截。给你的SignalRHub类加上[AllowAnonymous]特性：

[AllowAnonymous]
public class SignalRHub : Hub
{
    // 你的Hub方法逻辑
}

2. 正确配置web.config的location节点 #

之前你用通配符无效，大概率是没在location节点里明确禁用该路径的Windows认证，导致IIS同时启用两种认证时优先要求Windows认证。把这段配置加到web.config里：

<!-- 全局保持Windows认证 -->
<authentication mode="Windows" />

<!-- 配置SignalR路径允许匿名 -->
<location path="signalr">
  <system.web>
    <authorization>
      <allow users="*" />
    </authorization>
  </system.web>
  <system.webServer>
    <security>
      <authentication>
        <anonymousAuthentication enabled="true" />
        <!-- 必须禁用该路径的Windows认证，避免冲突 -->
        <windowsAuthentication enabled="false" />
      </authentication>
    </security>
  </system.webServer>
</location>

<!-- 如果还有其他需要匿名的控制器/Area，可类似配置 -->
<location path="Home/YourAnonymousAction">
  <system.web>
    <authorization>
      <allow users="*" />
    </authorization>
  </system.web>
</location>

这里的path="signalr"会自动匹配所有以/signalr开头的请求（包括negotiate、connect这些SignalR内部请求），不需要额外加通配符。

3. 同步IIS站点的认证设置 #

有时候web.config的配置会和IIS的局部设置冲突，建议手动去IIS里确认：

• 全局站点：同时启用Windows认证和匿名认证
• 找到站点下的signalr路径（如果没有就手动创建对应虚拟目录），进入“认证”功能：
  • 禁用Windows认证
  • 启用匿名认证

4. 验证SignalR协商请求 #

配置完后，直接在匿名设备的浏览器里访问http://MyWebsite/signalr/negotiate，如果返回200状态码和JSON数据，说明匿名访问已经生效。这时候再运行你的页面，SignalR的$.connection.hub.start()应该就能正常进入done回调了。

为什么之前的配置无效？ #

• 只给控制器加了[AllowAnonymous]，但没给SignalR Hub加，Hub自身的权限校验会拦截请求
• 启用匿名认证时出现500错误，大概率是因为没在location节点里禁用Windows认证，IIS同时启用两种认证导致冲突
• web.config的location节点不需要通配符，path="signalr"已经是前缀匹配了

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