解决IIS同一站点ID下多应用Cookie过多致请求头过长问题

遇到这种因多应用独立Cookie导致请求头超标问题很常见，尤其是在IIS 7.5这种对请求头限制相对严格的环境下。下面是几个经过实践验证的可行方案，按优先级排序：

1. 共享认证Cookie（最推荐的根本解决方案） #

既然所有应用都在同一个站点ID下，完全可以让它们共用同一个IdentityServer颁发的认证Cookie，而非每个应用都生成独立Cookie。这样请求头里只会携带一个Cookie，从根源上解决头部体积问题。

配置步骤： #

• IdentityServer端：在客户端配置中，确保所有应用的RedirectUris、PostLogoutRedirectUris等配置正确，同时设置统一的CookieDomain（比如你的企业主域名，如yourcompany.com）和CookiePath为/。
• 客户端应用端：在每个应用的认证配置里，指定相同的Cookie域和路径，并且关闭每个应用单独保存Token的设置：

services.AddAuthentication(options =>
{
    options.DefaultScheme = "Cookies";
    options.DefaultChallengeScheme = "oidc";
})
.AddCookie("Cookies", options =>
{
    options.Cookie.Domain = "yourcompany.com"; // 和IdentityServer保持一致
    options.Cookie.Path = "/";
    options.Cookie.HttpOnly = true;
    options.Cookie.SecurePolicy = CookieSecurePolicy.Always;
})
.AddOpenIdConnect("oidc", options =>
{
    options.Authority = "https://your-identityserver-url";
    options.ClientId = "your-client-id";
    options.ClientSecret = "your-client-secret";
    options.ResponseType = "code";
    options.SaveTokens = false; // 不需要每个应用单独存储Token，共享Cookie即可
    options.Scope.Add("openid");
    options.Scope.Add("profile");
});

• IIS设置：确保站点的“Cookie设置”里没有限制域或路径的额外配置，允许跨应用共享Cookie。

2. 使用Reference Token替代JWT Token #

如果共享Cookie的方案因业务限制无法实施，可以考虑把JWT Token换成Reference Token。JWT是自包含的，包含了所有用户和权限信息，体积较大；而Reference Token只是一个短字符串，实际的Token内容存储在IdentityServer服务器端，客户端应用需要向IdentityServer校验Token的有效性。

配置步骤： #

• IdentityServer端：在客户端配置中，将AccessTokenType设置为AccessTokenType.Reference：

new Client
{
    ClientId = "your-client-id",
    // 其他配置
    AccessTokenType = AccessTokenType.Reference,
    // 确保启用了Reference Token的存储和校验服务
}

• 客户端应用端：不需要额外修改认证流程，IdentityServer的客户端SDK会自动处理向服务器校验Token的逻辑。这样Cookie里存储的Token会小很多，减少单个Cookie的体积。

3. 压缩请求头（临时缓解方案） #

IIS 7.5支持对请求头进行压缩，开启后可以有效减小请求头的体积，可能让5个以上Cookie的请求头刚好符合限制。

配置方式： #

• 通过IIS管理器：找到目标站点，双击“压缩”功能，勾选“启用动态内容压缩”，在“压缩设置”里确保包含请求头的压缩。
• 或者通过web.config配置：

<system.webServer>
    <httpCompression directory="%SystemDrive%\inetpub\temp\IIS Temporary Compressed Files">
        <scheme name="gzip" dll="%Windir%\system32\inetsrv\gzip.dll" />
        <dynamicTypes>
            <add mimeType="text/*" enabled="true" />
            <add mimeType="message/*" enabled="true" />
            <add mimeType="application/javascript" enabled="true" />
            <add mimeType="application/json" enabled="true" />
            <add mimeType="*/*" enabled="false" />
        </dynamicTypes>
    </httpCompression>
    <urlCompression doStaticCompression="true" doDynamicCompression="true" />
</system.webServer>

4. 调整IIS请求头大小限制（应急方案） #

如果以上方案都无法快速实施，可以临时调整IIS的请求头大小限制，避免400错误。但注意这只是临时应急，长期来看还是要解决Cookie膨胀的根源问题，过大的请求头可能带来安全风险。

配置方式： #

• 修改applicationHost.config文件（位于%Windir%\System32\inetsrv\config），找到对应的站点配置，添加或修改requestLimits节点：

<location path="YourSiteName">
    <system.webServer>
        <security>
            <requestFiltering>
                <requestLimits maxHeaderSize="65536" /> <!-- 调整为合适的值，默认是16384 -->
            </requestFiltering>
        </security>
    </system.webServer>
</location>

• 或者在站点的web.config里添加：

<system.webServer>
    <security>
        <requestFiltering>
            <requestLimits maxHeaderSize="65536" />
        </requestFiltering>
    </security>
</system.webServer>

修改后需要重启IIS生效。

总结 #

优先选择共享认证Cookie或使用Reference Token，这两个方案从根本上解决了Cookie过多或过大的问题；压缩请求头和调整IIS限制属于临时缓解或应急方案，适合快速恢复业务但长期需要优化的场景。

内容的提问来源于stack exchange，提问作者j-hurst