http-proxy-middleware代理经IIS部署后非OPTIONS请求返回500问题求助

核心原因定位 #

该问题本质是IIS默认会拦截非预期状态码的后端响应，自动插入自带的500错误页面内容，同时覆盖响应状态码，导致最终返回给前端的响应混杂了代理服务返回的正确业务数据和IIS的错误内容，状态码被篡改为500。

修复步骤 #

1. 补充IIS站点配置，强制透传后端响应
   编辑站点的web.config文件，新增httpErrors配置禁止IIS覆盖响应，同时配置参数保留原始响应状态，修改后完整配置如下：

<?xml version="1.0" encoding="UTF-8"?>
<configuration>
    <system.webServer>
        <!-- 透传后端返回的所有响应，禁止IIS插入自定义错误内容 -->
        <httpErrors existingResponse="PassThrough" />
        <rewrite>
            <rules>
                <rule name="ReverseProxyInboundRule1" stopProcessing="true">
                    <match url="(.*)" />
                    <action type="Rewrite" url="http://localhost:5001/{R:1}" />
                    <!-- 保留代理服务返回的原始响应状态码 -->
                    <serverVariables>
                        <set name="RESPONSE_STATUS" value="{RESPONSE_STATUS}" />
                    </serverVariables>
                </rule>
            </rules>
        </rewrite>
    </system.webServer>
</configuration>

2. 调整ARR（应用请求路由）配置
   打开IIS的ARR功能，进入「代理设置」：

• 取消勾选「启用响应缓冲」
• 勾选「保留客户端的主机头」
  保存后重启ARR服务和对应的IIS站点。

3. 可选排查项
   如果修改后仍有问题，开启IIS的「失败请求跟踪」功能，过滤500状态码的请求，查看具体是IIS的哪个模块触发了错误，常见的额外问题包括：

• IIS默认开启的动态压缩模块和代理服务返回的压缩格式冲突
• 请求头中包含IIS不允许的特殊字符，触发请求校验拦截
• IIS层级配置了CORS规则，和Node服务的CORS配置返回重复头信息触发错误

验证方法 #

修改配置后直接通过IIS站点访问代理接口，检查状态码是否正常、响应体是否仅包含业务接口返回的正确内容即可。

内容的提问来源于stack exchange，提问作者Enzo B.