更新实际答案：我选择了下面的单个答案，因为它鼓励我们更深入地研究实际机器、实际用户等。该问题仅出现在 Microsoft Word 文件中，并且仅针对特定用户。观察用户行为后，发现这种情况似乎发生在那些在上传过程中保持 Word 打开的用户身上。我们的假设是，Word 在文件仍在上传时将 SmartTag 信息写入文件，导致文件损坏。这种情况似乎更多地发生在远程/VPN 连接上，因为上传速度较慢，这给我们带来了更高的 Word 写入文件的统计概率。LAN 上的上传速度非常快，因此 Word 写入的可能性较低。
我们发现一个问题，即文件上传有时会损坏。这种情况不会发生在实际位于 LAN 上的用户身上，只有使用 VPN 连接的用户才会发生。他们都运行相同的映像：干净的 IE6、XP。服务器是使用 Apache Commons File Upload 1.2.1 库的 Tomcat 5.0.28。VPN 连接确实跨越了北美和印度，因此延迟可能会很大。
针对提出的问题的答复：
有没有办法可以进一步缩小范围，比如这是否仅来自特定站点、特定用户或特定机器上的用户？ 不，唯一的共同点是 VPN 连接，尽管有一组 VPN 用户从未遇到过此问题，而其他人则经常遇到此问题
损坏是否似乎发生在一天中的某个特定时间？不，随时都有可能发生
他们是否能够使用不同的协议传输文件，并且是否存在相同的损坏问题？当文件上传导致版本损坏时，他们总是通过电子邮件发送文件。通过电子邮件发送文件总是有效的。
您是否能够将文件从您的网站复制到他们的网站，并看到相同的结果，即间歇性损坏？如果损坏是双向发生的，这可以告诉您是否是传输过程本身导致的。这是一个好主意。我会尝试一下并汇报。
有没有办法在他们那边设置一个服务器来存储数据，然后定期在两个服务器之间运行脚本数据同步？想法不错，但由于法律和人员配备的原因，这不可能实现。
答案1
可能是延迟本身导致了问题，不一定是 VPN。
有没有办法可以进一步缩小范围，比如这是否仅来自特定站点、特定用户或特定机器上的用户？
损坏是否似乎发生在一天中的某个特定时间？
他们是否能够使用不同的协议传输文件，并且是否存在相同的损坏问题？
您是否能够将文件从您的网站复制到他们的网站，并看到相同的结果，即间歇性损坏？如果损坏是双向发生的，这可以告诉您是否是传输过程本身导致的。
有没有办法在他们那边设置一个服务器来存储数据，然后定期在两个服务器之间运行脚本同步数据？像 RSync 这样的程序应该能够弥补通信噪音。Unison 也可以工作，这样你就有了两个带有数据副本的服务器，并且你的远程站点可以更快地访问数据，这为你带来了额外的好处。