上传看起来损坏：在两端比对哈希

打不开已上传文件的接收方，常听说是 VPN 把它弄坏了。这是假设，不是观察，而且可以验证。在触碰隧道之前，先确定目标端现在保存的对象，是否与本该发送的对象不同。其余一切都由这个答案决定。

从本应发送的字节开始，而不是从投诉开始

挑一个能复现问题的无害文件，或者在策略允许它离开源环境时使用真实文件。传输之前记下两件事：精确的字节大小，以及一个现代的内容哈希。文件名、时间戳和预览都是元数据，没有一项能标识内容。

用两端都能运行的算法计算哈希，并写下你用的是哪一种。拿 SHA-256 和 MD5 相比不算比较，拿两个碰巧同名的不同文件相比也不算比较。

PS> Get-FileHash -LiteralPath "C:\uploads\report.csv" -Algorithm SHA256
Hash                                                        Path
----                                                        ----
9F2C...                                                      C:\uploads\report.csv

Microsoft 的 Get-FileHash 参考 记录了该命令及其算法参数，而这正是比较得出毫无意义的差异时人们跳过的那一部分。

每个阶段一个哈希，同一种算法

现在在已保存对象最终所在的位置，用获准的方法计算同一个算法，而不是用一份经过别的工具处理的副本。把收到的文件存到本地再对这份副本做哈希，会多出一个你没有验证过的步骤。

如果服务对外提供自己的完整性数值，请把它当作独立的观察。服务商报告的校验和只能说明服务商认为自己存了什么，这与你的客户端发出的内容并不是同一个说法。

可能的结果有三种，指向不同方向。哈希相同，说明字节原样到达。哈希不同但有已知的转换，说明服务有意生成了新对象。哈希不同且没有任何转换，说明两点之间有环节改动了内容，下一步就是找出最早发生这件事的那一处边界。

把传输失败与转换区分开

部分上传和损坏的上传在文件浏览器里看起来一样，却是两种不同的故障。检查传输是否完成：应用日志显示请求被中断、已保存文件的大小只是源文件的前缀、或者对象其实是存成预期扩展名的错误页面，这些都说明传输没有完成，而不是字节被改动。

转换是另一种常见解释。会重新压缩图片、重写 CSV 行尾或转换文档的服务，会合法地产生与源文件不同的哈希，那不是损坏。要比对的是声称自己是忠实副本的那个阶段，而不是最终的呈现格式。

延迟和丢包属于第三类。它们会让客户端超时、重试或放弃，而这些都不意味着服务器接受的字节被悄悄改过。在把责任推给隧道之前，先看传输结果。

不改变一切，另试一条路径

如果哈希确实不同，而且不涉及任何转换，就用同一个文件、客户端、协议和目标，换一条受支持的路径重做，比如改用本地网络而不是 VPN。只改一个变量。同时更换客户端、端点和工具，得到的结果你无法归因。

两个方向都要让比较保持诚实。哈希只告诉你两点在内容上一致或不一致；它不告诉你哪一侧可信，所以要把预期值和验证都放在你真正依赖的信任模型之内。

在工单里用一句具体的话收尾：传输提前中断、应用转换了对象、存储改动了它，或者字节一致而读取才是故障。每一种都有不同的责任方，没有一种默认就是 VPN。