这种情况可能只是局部现象，但问题的根源在于，只要你通过防火墙传递 PostScript（可能还有其他类型的打印作业），就可能发生这种情况应用程序控制或启用了类似的功能（例如，因为您有一个到远程站点的 VPN 隧道）。
我们跑布鲁克斯 RPM在台式机上接受来自 SAP 服务器的 PostScript 打印作业。基本上，它应用一个脚本将输入（PostScript 文件）转换为 PDF，为其指定一个好听的名字，然后将其发送到用户的电子邮件地址，并带有预先格式化的主题行，以便于转发。SAP 服务器物理上位于我们的站点。我在这里和远程站点都有 SAP 用户，我们通过 VPN 隧道连接到远程站点（连接的详细信息无关紧要）。
有时候，某些文档在打印时会向服务器发送无限重复的打印作业。症状如下：
- 不止一种类型的文档存在此问题
- 该错误可以在“问题”文档中一致重现
- 打印件不完整，但有趣的是，每份打印作业的不完整状态都不同
- 该问题仅发生在远程站点
- 从两端来看，网络流量看起来完全正常（即没有丢包等），并且其他打印作业也没有出现问题
要修复该问题，我们必须停止 Windows 打印机后台服务，清除 %WINDIR%\system32\spool\PRINTERS 并重新启动打印机后台服务 - 只有这样，重复的打印作业才会停止。我发现每次打印输出的内容都不一样，这很奇怪 - 我猜 SAP 服务器在响应来自打印服务器的每个故障报告时一直在生成格式错误的 PostScript 文件，但当我们检查 SAP 打印机后台日志时，这一猜想被推翻了 - 每次打印尝试都只有一个输出记录。根据我对打印后台处理的理解（我承认我缺乏这种理解），打印作业不应该每次都有不同的内容，因为内容实际上并没有被重新生成。
事实证明，我只对了一半 - 打印作业确实被破坏了，但不是由 SAP 造成的。
答案1
tl;dr 版本：它是 SonicWALL App Control。
编写脚本的人、远程站点管理员、我的老板和我坐在我的站点上解决问题。我们设法将问题归咎于传输过程中发生的某些事情 - RPM 服务器的线轴中的示例 PS 文件已损坏，但当我们将其转换为 PDF 时，客户端打印机线轴上的匹配 PS 文件完全正常。此外，使用远程站点管理员的笔记本电脑（请记住，他和我们一起在我的站点）打印有问题的文档并没有引发洪水。
我们从远程机器触发了一次洪水攻击，并再次进行了网络检查 - 流量看起来完全正常。然后远程站点管理员查看了一份不相关的日志，发现了一些完全不对劲的东西：
事实证明，SonicWALL App Control 错误地将打印作业的流量识别为 IM 文件传输，并在检测到后切断连接 - 这解释了打印作业内容不一致的原因。一旦我们在防火墙上将打印服务器列入白名单，问题就消失了。
现在看来这很明显，但事后看来却很清楚。
因此，总而言之：如果您在通过防火墙的打印作业时遇到问题，请检查它们是否被任何类型的应用程序过滤所拦截。