IIS Express+VS2019环境下Chrome无法正常加载MP3问题

核心问题分析 #

MP3文件本身正常（拖拽到浏览器可播放），但通过项目URL访问时，服务器返回的并非原始二进制文件，而是被篡改的内容（异常Base64结尾），说明请求未被正确映射到静态文件，而是被路由/其他处理程序拦截并返回了错误内容。

排查与解决步骤 #

• 检查路由拦截规则
  若项目使用MVC/WebApi路由，确认路由配置未将静态文件路径识别为控制器请求。在RouteConfig.cs中添加忽略路由规则，确保音频文件路径不被路由处理：

  routes.IgnoreRoute("{folder}/{*pathInfo}", new { folder = @"Content/Audio" });
  

  或宽泛忽略所有静态文件路由：

  routes.IgnoreRoute("{resource}.axd/{*pathInfo}");
  routes.IgnoreRoute("{*staticfile}", new { staticfile = @".*\.(mp3|css|js|gif|jpg|png)$" });
  

• 验证IIS Express的MIME类型配置
  即使web.config已添加mime映射，IIS Express全局配置可能覆盖它：

  1. 找到项目.vs\config\applicationhost.config文件（无此文件则找%USERPROFILE%\Documents\IISExpress\config\applicationhost.config）
  2. 查找<mimeMap>节点，确认存在<mimeMap fileExtension=".mp3" mimeType="audio/mpeg" />
  3. 若有重复或错误映射（如mimeType设为video/*），删除后重启IIS Express

• 检查文件编码属性
  右键项目中的MP3文件→属性→高级，确保内容编码设置为(无)。若误设为UTF-8等文本编码，服务器会将二进制MP3当作文本处理，导致内容篡改。

• 排查URL重写规则
  若web.config中有<rewrite>节点，暂时注释所有重写规则，测试MP3是否能正常访问。若恢复正常，说明有重写规则错误改写了MP3请求。

• 测试请求响应细节
  用curl或Postman请求MP3的URL，查看：

  • 响应头是否包含Content-Type: audio/mpeg，且Content-Length与本地文件大小一致
  • 响应内容是否为二进制（而非文本/Base64），若为文本则说明请求被错误路由到控制器或其他处理程序

• 检查HTTP Handler配置
  查看web.config中的<httpHandlers>节点，确保没有针对.mp3的自定义handler拦截请求：

  <httpHandlers>
    <!-- 移除任何针对.mp3的handler配置 -->
  </httpHandlers>
  

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