部署至IIS服务器后AngularJS调用ASP.NET API返回500错误排查

1. 核对IIS应用程序池配置 #

• 确保应用程序池的.NET版本与本地VS调试环境完全一致，比如本地用.NET Framework 4.8，IIS里也要对应选择该版本
• 检查应用程序池身份权限：如果API需要访问数据库、本地文件或其他资源，确认运行身份（如ApplicationPoolIdentity、NetworkService）拥有对应读写权限——本地调试用的是当前用户权限，部署后权限范围可能不同

2. 确认请求路径匹配 #

• 本地VS调试的站点根路径可能和IIS部署的不一致，比如IIS绑定了虚拟目录，此时请求路径/Hashmaps/可能需要改为/虚拟目录名/Hashmaps/
• 打开浏览器开发者工具的Network面板，查看实际发送的请求URL，验证是否与API路由规则匹配

3. 获取详细错误信息 #

• 修改项目的Web.config，开启详细错误输出，替换相关配置：

  <system.web>
    <customErrors mode="Off"/>
  </system.web>
  <system.webServer>
    <httpErrors errorMode="Detailed"/>
  </system.webServer>
  

  重新部署后触发请求，会返回具体的500错误详情（比如参数绑定失败、未处理的业务异常等）
• 在API方法内添加日志记录（如写入文本文件），记录请求参数、方法执行节点，定位是参数解析阶段还是业务逻辑阶段出错

4. 检查参数序列化与绑定 #

• 对比AngularJS发送的hashOb、feature对象结构，与ASP.NET API的参数类是否完全匹配：包括属性名（注意大小写敏感问题，部分绑定规则会区分）、必填字段是否为空
• 在Network面板确认请求的Content-Type是否为application/json（AngularJS的$http.post默认会设置，但需验证）
• 排查复杂对象是否存在循环引用，本地调试环境的序列化配置可能允许循环引用，部署后触发序列化失败

5. 检查IIS请求限制 #

• 如果请求携带的数据量较大，确认IIS未限制POST请求大小，修改Web.config调整相关参数：

  <system.web>
    <httpRuntime maxRequestLength="1048576" /> <!-- 单位KB，此处设为1GB -->
  </system.web>
  <system.webServer>
    <security>
      <requestFiltering>
        <requestLimits maxAllowedContentLength="1073741824" /> <!-- 单位字节，此处设为1GB -->
      </requestFiltering>
    </security>
  </system.webServer>
  

• 确认IIS已安装对应模块：ASP.NET项目需确保ASP.NET模块启用，ASP.NET Core项目需安装ASP.NET Core Module

6. 验证外部依赖可用性 #

• 如果API涉及数据库操作，确认IIS服务器能正常连接数据库：检查连接字符串中的服务器地址、账号密码是否正确（本地可能用LocalDB，部署后需改为正式数据库地址）
• 核对部署后数据库的表结构、数据权限与本地是否一致，避免因表字段缺失、权限不足导致操作失败

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