如何配置 SQL 存储过程的传出连接？
我正在开发一个使用 Microsoft SQL 服务器的 .NET 项目。在这个项目中，我需要一个使用远程 Web 服务的 CLR 存储过程（用 C# 编写）。因此，当存储过程在 SQL 服务器上执行时，它会调用 Web 服务，从而将数据包发送到远程位置。问题是，当执行 SP 时，我得到： “System.Net.WebException：请求失败，HTTP 状态为 403：禁止。”
数据库用户拥有完全权限，部署的 CLR 程序集和 SP 甚至被标记为“不安全”，我尝试对其进行签名等，因此任何这些都不会导致问题。
当我执行完全相同的 C# 代码，但从一个简单的控制台应用程序而不是作为 SP 执行时，一切都工作正常。因此，我开始怀疑与网络相关的问题，并在执行 SP 和控制台应用程序版本时运行数据包嗅探器。
我意识到发出的数据包具有不同的目标 IP 地址：控制台应用程序将数据包直接发送到 Web 服务 IP，而 SP 将数据包发送到我们公司使用的代理服务器。由于网络策略，后者是不允许的，这解释了“403 Forbidden”例外。
所以我的问题归结为：如何将 SP/MS SQL 服务器配置为不使用该代理？我希望它将数据包直接发送到 Web 服务 IP，就像测试控制台应用程序一样。 （同样，C# 代码是相同的，因此这不是编程问题）。
我已禁用 Internet Explorer 中的所有代理设置，以防 SQL 服务器继承这些设置或其他设置。然而，没有运气。
任何帮助将不胜感激！
此致， 彼得
I am working on a .NET project which uses Microsoft SQL server. In this project, I need a CLR stored procedure (written in C#) that uses a remote web service. So, when the stored procedure is executed on the SQL server, it makes web service calls and thus sends packets to a remote location. The problem is that when executing the SP I get:
"System.Net.WebException: The request failed with HTTP status 403: Forbidden."
The database user has full permission, the deployed CLR assembly and SP are even marked "unsafe", I tried signing it etc., so any of that is not causing the problem.
When I am executing the very same C# code, but from a simple console application instead of as a SP, it all works fine. So I started to suspect a network related problem and had a packet sniffer running when executing both the SP and the console app version.
What I realized was that the packets sent out had different destination IP addresses: the console app sent the packets directly to the web service IP while the SP sent the packets to a proxy server we use in our company. Due to network policies the latter is not allowed and that explains the "403 Forbidden" exception.
So my question boils down to this: How can I configure the SP/MS SQL server to NOT use that proxy? I want it to send the packets directly to the web service IP, just like the test console app. (again, the C# code is the same , so it's not a programming matter).
I've disabled all proxy settings in Internet Explorer in case the SQL server inherits these settings or something. However, no luck.
Any help would be greatly appreciated!
Best regards,
Peter
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
不要从 SQL CLR 进行 HTTP Web 调用。
从外部进程进行所有 Web 服务调用。除非您希望发现生产服务器因工作人员饥饿而冻结，并且所有线程都在 CLR 事件中被阻止。你已被警告过。
Don't make HTTP web calls from SQL CLR.
Make all Web service calls from an outside process. Unless you want to find your production server frozen in worker starvation with all threads blocked in CLR events. You have been warned.
最可能的解释是某种网络级透明代理。我会与管理/管理您的网络的任何人讨论这个问题。
The most likely explanation is some kind of network level transparent proxy. I would discuss the issue with whoever manages/administers your network.