相同代码Blazor WASM应用双子域名部署其中一个出现框架DLL完整性错误

问题原因定位 #

这种同代码不同站点的完整性校验失败，90%以上的场景是站点反向代理层对静态资源做了额外修改，和构建阶段生成的哈希值不匹配导致，可按以下顺序排查：

排查步骤 #

• 优先验证Nginx压缩配置差异
  直接对比两个子域名同DLL资源的响应头，执行命令：
  curl -I https://subdomain2.domain.com/_framework/Microsoft.AspNetCore.Components.WebAssembly.Authentication.dll
  如果subdomain2的响应头带有Content-Encoding: gzip或Content-Encoding: br，而subdomain1没有，说明subdomain2的Nginx对/_framework下的二进制资源开了动态压缩。Blazor构建时生成的integrity哈希是基于未压缩的原始文件计算，浏览器拿到压缩后的文件重新计算的哈希自然和预设值不匹配，触发拦截。
• 检查Nginx内容替换配置
  看subdomain2的Nginx配置是否加了全局sub_filter规则用来替换文本内容（比如批量替换接口地址），这类规则如果没有限定仅作用于html/js/css等文本类型，会修改二进制DLL的内容，直接导致文件哈希变化。
• 校验文件完整性
  分别下载两个站点服务器上的Microsoft.AspNetCore.Components.WebAssembly.Authentication.dll文件，和本地构建生成的对应文件做SHA256校验：
  • Windows下执行：Get-FileHash -Algorithm SHA256 对应文件路径
  • Linux下执行：sha256sum 对应文件路径
    如果subdomain2的文件哈希和本地构建结果不一致，说明文件上传时损坏（比如FTP用了ASCII模式传输二进制文件），或部署时覆盖了错误版本的文件。
• 核对blazor.boot.json配置
  对比两个站点的/_framework/blazor.boot.json文件，确认对应DLL的integrity值完全一致，排除部署时误替换配置文件的问题。
• 排查缓存问题
  确认subdomain2是否接入CDN，或Nginx配置了过久的静态资源缓存，导致旧版本的DLL或blazor.boot.json被缓存，和当前版本的哈希不匹配。

对应解决方法 #

• 压缩问题：在subdomain2的Nginx配置中新增规则，关闭框架资源的压缩：

  location /_framework {
      gzip off;
      brotli off;
      expires 1y; # 按需保留缓存配置
  }
  

• 内容替换问题：给sub_filter规则增加文件类型限制，仅作用于文本资源，示例：

  location / {
      sub_filter "待替换内容" "目标内容";
      sub_filter_types text/html text/css application/javascript;
      sub_filter_once off;
  }
  

• 文件损坏问题：删除subdomain2站点的所有已部署文件，重新上传构建生成的完整publish包，传输时强制使用二进制模式。
• 缓存问题：清空CDN缓存，或给静态资源配置协商缓存规则，避免旧版本资源长期留存。

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