故障背景与现象还原
在某中型企业的内部管理系统升级项目中，开发团队将前端应用部署于Nginx反向代理之后，后端API服务托管在Windows Server 2019上运行的IIS（Internet Information Services）服务器。近期，运维团队在对服务器进行例行维护时执行了一次计划内的重启操作。重启完成后，前端页面加载正常，但在尝试提交表单或调用需要身份验证的API接口时，浏览器控制台频繁报错：CORS policy: Response to preflight request doesn't pass access control check（跨源资源共享策略：预检请求未通过访问控制检查）。
值得注意的是，在重启前的测试阶段，该接口运行完全正常。重启瞬间，部分静态资源加载无误，但所有涉及POST、PUT或DELETE方法的非简单请求均失败。开发人员初步怀疑是代码逻辑错误，但Git版本控制显示自上次成功部署以来，前后端代码均未发生任何变更。这一矛盾现象指向了服务器环境或配置层面的问题。
根因深度分析
经过对服务器日志、IIS配置及网络抓包的详细复盘，我们确定了导致CORS策略拦截的三个核心因素：
1. IIS CORS模块配置未持久化至磁盘
IIS中安装的CORS模块允许管理员在IIS管理器界面动态设置跨域策略。然而，某些特定版本的IIS配置管理存在缓存机制，若未在修改后显式执行AppCmd保存或重启IIS配置服务，策略可能仅存在于内存中。服务器重启后，内存数据丢失，而IIS默认行为可能回退到拒绝所有非简单请求的策略，或者未能正确读取applicationHost.config中的对应节点。
2. 防火墙与预检请求（OPTIONS）的处理差异
CORS规范规定，对于非简单请求（如包含自定义Header或Content-Type为application/json的请求），浏览器会先发送一个OPTIONS方法的“预检请求”（Preflight Request）。只有当服务端对该OPTIONS请求返回正确的Access-Control-Allow-Origin等响应头且状态码为2xx时，真正的业务请求才会发出。
在Windows Server环境中，如果启用了高级安全性Windows防火墙，且自定义规则未明确允许OPTIONS方法通过，或者防火墙策略在重启后未能正确绑定到特定的应用程序池，可能导致预检请求被静默丢弃或返回403 Forbidden。不同于常规的TCP/IP连接拦截，应用层防火墙规则若未针对HTTP动词进行细化，极易在此类场景下引发故障。
3. HTTP.sys 缓存与动态端口分配冲突
Windows内核HTTP服务（HTTP.sys）负责处理底层的HTTP监听。重启后，如果IIS的应用程序池回收机制导致监听端口发生变化，或者HTTP.sys的URL保留规则（URL Reservation）未在服务启动初期正确加载，可能导致请求路由错误。此外，HTTP.sys自带的缓存策略可能在重启后重置，若后端API未正确配置缓存控制头，部分浏览器可能会错误地缓存之前的403或500错误响应，导致即使服务器配置修复，前端仍持续报错。
系统性排查与修复步骤
第一步：验证并重新应用IIS CORS配置
首先，登录到Windows Server，打开“IIS管理器”。导航至对应的站点，双击打开“CORS”图标。
- 检查当前设置：确认
Allowed Origins列表中是否包含了前端域名的确切地址（包括协议和端口，如https://frontend.example.com:443）。 - 强制保存配置：在IIS管理器中，点击右侧操作栏的“应用（Apply）”。更稳妥的方式是使用命令行工具
%windir%\system32\inetsrv\appcmd.exe手动保存配置，确保更改写入%SystemDrive%\inetpub\temp\apphost\config目录下的配置文件。 - 查看Web.config：直接编辑站点根目录下的
web.config文件，确保存在如下配置段：
<configuration> <system.webServer> <cors enabled="true"> <add origin="https://your-frontend-domain.com" allowCredentials="true"> <allowMethods> <add method="GET" /> <add method="POST" /> <add method="PUT" /> <add method="DELETE" /> <add method="OPTIONS" /> </allowMethods> </add> </cors> </system.webServer> </configuration>
第二步：排查Windows防火墙对OPTIONS请求的限制
使用netsh advfirewall monitor show firewall rule name=all命令或图形化界面“高级安全Windows防火墙”，检查是否有规则拦截了入站流量。
- 创建专用规则：新建一条入站规则，协议类型为TCP，本地端口为IIS绑定的端口（通常为80或443）。
- 细化动作：在“操作”选项卡中，选择“允许连接”。在“作用域”或“条件”中，虽然Windows原生防火墙难以直接基于HTTP Method（如OPTIONS）进行过滤，但需确保没有第三方IPS/IDS设备或自定义脚本在重启后重新加载并阻断了特定类型的HTTP请求。
- 测试连通性：在另一台机器上使用
curl -v -X OPTIONS http://server-ip/api/test -H "Origin: https://frontend.com" -H "Access-Control-Request-Method: POST"命令，模拟浏览器预检请求，观察返回值是否包含Access-Control-Allow-Origin。
第三步：清除浏览器缓存与HTTP.sys状态
由于故障发生在重启后，可能存在旧配置残留。
- 服务端重置：在命令提示符（管理员）中运行
iisreset重启IIS服务，随后运行net stop http && net start http以重置HTTP.sys状态。 - 客户端清理：指导前端开发人员或测试人员清除浏览器缓存，特别是硬刷新（Ctrl+F5），以排除浏览器缓存了之前的错误响应头。
- 禁用缓存标头：在开发环境中，建议在API响应中添加
Cache-Control: no-cache, no-store, must-revalidate标头，防止浏览器缓存CORS预检结果。
第四步：启用详细日志记录以备后续监控
为了预防未来类似问题的发生，建议在IIS中启用“失败请求跟踪规则（Failed Request Tracing Rules）”。
- 配置规则监控HTTP状态码4xx和5xx。
- 重点捕获带有
X-CORS-ERROR或相关自定义Header的失败请求。 - 定期审查
\inetpub\logs\FailedReqLogFiles目录下的XML日志，定位具体的CORS验证失败点。
总结与建议
Windows Server重启引发的CORS故障通常并非代码逻辑错误，而是配置持久化、防火墙策略重置或HTTP服务状态不一致所致。运维人员在执行系统维护时，应遵循以下最佳实践：
- 配置即代码：避免仅依赖IIS图形界面进行配置，应将CORS设置直接写入
web.config并纳入版本控制系统。 - 重启后验证：关键服务重启后，应立即通过自动化工具或手动脚本验证API接口的连通性及响应头完整性。
- 监控预检请求：在监控系统中增加对
OPTIONS请求成功率的监控告警，以便在故障初期快速发现预检拦截问题。