WCF 无法建立连接,因为目标机器主动拒绝
我刚刚使用 net.tcp
实现了一个简单的 WCF 服务器。
首先,我使用127.0.0.1
作为服务器地址,客户端能够连接WCF服务。
一切都好。但是当我尝试使用内部 IP 192.xxx
时,出现错误:
无法建立连接,因为目标机器主动拒绝
知道可能导致此情况的原因吗?
最美好的祝愿
PS:我禁用了 WCF 上的身份验证。甚至关闭所有防火墙...不起作用...
I just implemented a simple WCF server using net.tcp
.
First, I use 127.0.0.1
as server address and client able to connect the WCF service.
Everything is Ok. But when I try to use the internal IP 192.x.x.x
I get an error:
No connection could be made because the target machine actively refused it
Any idea what may cause this?
Best Wishes
PS: I disabled auth on WCF. Even turn off firewall all...Not worked...
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(6)
好吧,当我忘记安装必要的组件时,我收到了此错误消息。请参阅链接使用netTcpBinding配置WCF服务
(步骤摘要)...
Well, I got this error message when I forgot to install necessary components. see link Configuring WCF Service with netTcpBinding
(summary of steps)...
您在客户端和服务器上都使用 192.xxx 吗?我记得不久前看到一个问题,对于 TCP,客户端和服务器名称需要匹配(与消息属性之一相关),因此,如果您使用“localhost”定义服务,并使用
<机器名称>
就会有问题。Do you use 192.x.x.x on both client and server? I remember seeing an issue a while back in which for TCP the client and server names needed to match (something related to one of the message properties), so if you define the service with "localhost" and the client with
<machine name>
there would be a problem.如果逻辑地址相同并且服务器端点已配置为“listenUri”并且客户端行为配置为使用
地址,则物理客户端和服务地址可能不同。在我们的例子中,这是我们的代理/防火墙配置所必需的。实际上,客户端调用防火墙,服务器在本地侦听转发的请求。对于 IIS 托管的服务,请检查以下各项:
对于非IIS 托管服务,您可能需要配置命名空间预留(URLACL)。 http://msdn.microsoft.com/en-us/library/ms733768.aspx
还要确保适当的 Windows 服务正在运行,例如 Net.Tcp 侦听器。
The physical client and service addresses can differ if the logical address is the same and the server endpoint has been configured with a "listenUri" and the client behaviour is configured to use a
<clientVia>
address. In our case, this is required in for our proxy/firewall configuration. In effect, the client calls the firewall and the server listens locally for a forwarded request.For an IIS-hosted service, check the following:
For a non-IIS hosted service, you may need to configure a Namespace Reservation (URLACL). http://msdn.microsoft.com/en-us/library/ms733768.aspx
Also ensure the appropriate Windows Services are running, e.g. Net.Tcp listener.
如果您在 Visual Studio 中以调试模式运行,请确保您的解决方案端口号匹配。我见过几个实例,其中我选择了“属性”>“Web”>“自动分配端口”,并且来自的端点(在本例中是我的 silverlight 应用程序)与自动生成的端口不匹配。我通常在 .web 中将端口更改为 1318。
If you're running from within visual studio in debug mode, ensure your solution port numbers match. I have seen several instances where I had Properties>Web>Auto-Assign Port - selected and the endpoint from, in this case my silverlight app, didn't match the port auto generated. I usually change the port to 1318 in my .web.
今天我发现如果您的 WCF 服务类中有循环引用,也会出现此错误。我有一个方法无限地调用自身并导致此错误消息,这导致我来到这里。
因此,如果其他建议都不起作用,请检查您的代码,看看您是否正在执行任何递归功能,并确保您没有陷入无限循环。
Today I found out that this error will also show up if you have a circular reference in your WCF Service Class. I had a method that was calling itself infinitely and causing this error message, which led me here.
So if none of the other suggestions work, check your code to see if you're doing any recursive functionality and make sure you're not caught in an infinite loop.
我通过在应用程序配置中注释此设置解决了这个问题:
或者运行 Fiddler,它将在 127.0.0.1 处进行 WCF 调用,然后转发它。
完整的场景是,我在对其中一项服务进行 WCF 调用时遇到了同样的问题。调用将失败,并显示顶级错误消息“没有端点正在监听 http://LinuxIP:Port/...”,服务跟踪查看器日志显示内部异常为“无法建立连接,因为目标计算机主动拒绝它 127.0.0.1:8888< /em>
“。
原因是我已将此配置放入我的应用程序中,以捕获 Fiddler 中的传出流量。如果此配置到位,则需要运行 Fiddler 来执行 WCF 调用,以使其到达预期目的地。如果 Fiddler 是在这种情况下不运行此错误将会出现。注释此设置,WCF 调用将转到目的地。
I resolved this issue by either commenting this setting in the application configuration:
or, running Fiddler which would take the WCF call at 127.0.0.1 and then forward it.
The complete scenario is, I encountered the same issue with WCF calls made to one of the service. The calls would fail with top level error message "There was no endpoint listening at http://LinuxIP:Port/...", and service trace viewer log showing inner exception to be "No connection could be made because the target machine actively refused it 127.0.0.1:8888
".
The reason was that I had put this configuration in my application to capture the outgoing traffic in Fiddler. If this configuration is in place then the Fiddler needs to be running for the WCF calls to make it to the intended destination. If Fiddler is not running this error will be there. Comment this setting in such scenarios, and the WCF call will go to the destination.