我们有一个应用程序（excel 插件），配置为从 IE（WinInet）获取代理设置。这就是当今大多数现代应用程序的工作方式，它们只需挂接到您的系统/IE 代理设置并使用它们。IE 设置是使用 PAC 文件脚本，并且对所有其他应用程序都运行良好，没有问题。
这个应用程序可以运行几个小时，然后就坏了。这个问题非常不一致。我们使用 Wireshark 捕获网络流量，发现当它坏掉时是因为它绕过了代理并尝试直接访问。我以前见过这种情况，但它要么 100% 有效，要么不能 100%。在这种情况下，您可以在网络中看到该应用程序正在使用代理并且运行良好；然后由于某种奇怪的原因，它决定直接访问。
以下是我的观察和想法：
基于以上，我的结论是应用程序是问题所在。但是，供应商声称他们的其他客户都没有这个问题，所以他们拒绝调查。我倾向于相信他们是公平的，因为这是 Oracle，他们告诉我有一些大型企业正在使用它。
在我从事 IT 工作的这些年里，我从未见过这种行为 —— 当应用程序配置为使用代理/PAC 文件时，它却试图直接连接到互联网（当然假设它配置正确）。
- 无论成功还是失败，它所指向的 URL 都是完全相同的 - 这排除了 PAC 中导致问题的任何特定规则
- 当它失败时，之前和之后我都可以使用其他应用程序（如 IE）成功看到与其他 URL 的代理连接 - 这排除了在问题发生时无法访问代理的可能性。
- PAC 文件非常简单，没有任何规则来“直接”发送任何流量。
- 有一次，我以为当应用程序尝试访问互联网时，托管 PAC 文件的服务器可能无法访问。但是，我排除了这种可能性，因为在发生此错误时其他应用程序运行正常。我还创建了一个 PowerShell 脚本，该脚本在发生错误时不断执行 GET 以检索 http 状态 200。这一切都正常，这表明 PAC 文件服务器没有问题。
我接下来要研究的是下载 PAC 文件时发生的过程。有人知道如何排除故障或启用 WinInet 的日志记录吗？我在互联网上找不到任何相关信息。