先把当时的情况摆出来。sitemap 做成了压缩包提交，服务器对 .gz 返回 application/octet-stream。GSC 里状态一直是待处理，Bing 直接报文件格式错误。文件本身能正常解压，内容是合法的 urlset。
把日志和配置对完，能解释这个现象的基本就这几处。mime.types 里没有 .gz 的映射，nginx 按默认二进制流返回。也可能是CDN 又改写了一次 Content-Type，把源站的修正覆盖掉。
另外，压缩包里放的是索引文件，扩展名却写成了 sitemap.xml.gz 之外的名称。少数情况下是文件被压缩了两次，解压后仍是二进制。
动手时先看压缩包的响应头和实际内容
curl -sI https://www.example.com/sitemap.xml.gz | grep -i -E 'HTTP/|content-type|content-encoding'下载后解压，确认里面是合法的 XML
curl -s https://www.example.com/sitemap.xml.gz | gunzip | head -5接着在 nginx 里补上 gzip 的类型映射
types { application/gzip gz; }剩下的就是清掉 CDN 缓存后重新提交压缩包
curl -X PURGE https://www.example.com/sitemap.xml.gz怎么算真的好了，看的是同一批现象。压缩包返回的 Content-Type 是 application/gzip，解压后是完整 urlset，提交状态从待处理转为成功。
不确定类型时直接提交未压缩的 XML 更稳，压缩只省带宽，类型错了反而多花一轮排查时间。报错文案容易误导，真正的原因往往在相邻那一层的日志里。