更新：
在解决这个问题的过程中，我们意识到 HTTPS 流量不会受到“长 URL”问题的影响（当然，除非您的域名特别长）。这是因为 URL 的查询字符串在 HTTPS 请求消息中加密，因此代理或防火墙无法看到它。虽然我们确实调整了 Cisco 防火墙上的最大 URL 长度设置（这很有帮助），但我们也意识到我们的生产站点将完全采用 HTTPS，因此我们不必再担心这个问题。
几个月前，我在登录 meta.stackoverflow.com 时遇到了问题，于是我给 Stack Overflow 团队发了一封电子邮件寻求帮助。他们告诉我“我无法使用我的 OpenID 登录 - 故障排除提示”这让我相信我可能被一个强大的防火墙或代理所保护，阻止了长 URL。我在访问其他使用长 URL 的网站时也遇到了问题。
我正在使用第三方供应商的网站进行测试，他们的网站请求的.axd资源具有非常长的查询参数。我在使用他们的网站时遇到了很多问题，所以我再次认为代理或防火墙正在干扰。
我将要求我们的系统管理员团队调查这个“长 URL”问题，但如果可能的话，我想给他们更多关于查找位置的指导。我们的一位系统管理员说，他认为我们位于 Cisco Web 应用程序防火墙后面。我们可以查看此设备上是否有特定设置来查看它是否阻止了长 URL？还有其他常见的网络组件可以查看它们是否阻止了长 URL？
注意：下面是我采取的步骤，以确定问题出在网络组件上而不是我的个人机器上。
第三方供应商的网站无法正常工作当我从以下地址访问他们的网站时：
- 我在域内工作电脑上运行 Windows XP，并使用 IE8、Firefox 或 Chrome（从 IE8 连接时，Fiddler 甚至显示 HTTP 协议违规）。
- 来自域内 Windows Server 2k3 终端服务器的 IE8 和 Firefox。
- 域内 Windows 7 计算机上的 IE8 和 Firefox，并有域管理员登录。
- 通过有线连接连接到我们网络的域外 Windows 7 个人笔记本电脑上的 IE8。
第三方供应商的网站正常工作当我从以下地址访问他们的网站时：
- IE8 和 Firefox 在上述同一台个人笔记本电脑上，但通过穿过我们的网络堆栈的 WiFi 连接。
因为网站无法正常工作时的最低公分母是我们的公司网络堆栈，所以我认为问题很可能存在那里。
答案1
如果您认为路径中的设备阻止了长 URL，为什么不访问个人网站（或您选择的任何网站）并尝试重现？发送一个大请求，看看是否收到错误。
有些代理只允许 4 到 8k 之间的 URL 通过，所以也许您超出了这个范围？
对于 Cisco ACE，请查看这并搜索“请求 URL 的最大大小”。