Nginx环境下createObjectURL生成PNG下载链接文件损坏问题求助

针对Nginx部署环境下Swagger生成的PNG下载链接损坏问题，可按以下方向逐一排查：

• 确认API响应头的正确性
  检查浏览器网络工具中API返回的响应头：

  • 确保Content-Type为image/png，且未附加charset=utf-8（如果存在该charset声明，浏览器会将二进制数据按UTF-8文本解析，导致不可编码字节被替换为EF BF BD）。
  • 确认没有多余的Content-Encoding头（如gzip），除非API确实启用了压缩且Nginx正确处理了解压。

• 检查Nginx对API请求的转发配置
  如果API通过Nginx转发，需确保Nginx未篡改二进制响应：

  • 在API对应的location块中添加default_type image/png;或default_type application/octet-stream;，避免继承全局默认类型导致的解析错误。
  • 尝试禁用proxy_buffering：添加proxy_buffering off;，防止Nginx缓存响应时将二进制数据按文本处理。
  • 检查是否存在proxy_set_header Accept-Encoding等可能影响响应编码的配置，确保不对二进制响应启用压缩。

• 验证Swagger UI获取响应数据的方式
  确认JS代码中获取API响应的逻辑是否正确：

  • 使用fetch或XMLHttpRequest时，需设置responseType: 'blob'或responseType: 'arraybuffer'，确保直接获取二进制数据而非文本字符串。例如：

    fetch('/api/chart')
      .then(response => response.blob())
      .then(content => {
        const href = window.URL.createObjectURL(content);
        // 生成a标签逻辑
      });
    

  • 如果当前content是字符串类型，说明数据已被浏览器按UTF-8解析损坏，需修正响应获取方式。

• 跳过Swagger直接测试API下载
  直接在浏览器访问API的URL，查看下载的PNG文件是否正常：

  • 如果直接下载正常，问题出在Swagger UI的JS处理环节，重点排查响应数据的获取和Blob构造逻辑。
  • 如果直接下载也损坏，问题完全在Nginx对API响应的处理上，需重点调整Nginx的转发或响应头配置。

• 检查Nginx静态文件配置对Swagger的影响
  确认Swagger UI相关静态文件（如swagger-ui.js）的响应头：

  • 确保JS文件的Content-Type为application/javascript，且未附加不必要的charset声明，避免JS运行时的编码异常。

内容的提问来源于stack exchange，提问作者G. Cuthbert