C# IIS7 URL重写为WCF请求返回404（反向代理）

我使用的是IIS7.5、.NET4.0。我在当地工作

我已经安装了应用程序请求路由、Web场框架、WebDeploy和URLRewite来设置反向代理。这在很大程度上是可行的

我有两个网站：

• DefaultWebSite（端口80，应用程序池：默认应用程序池（.net 4））和
• 目标（端口8085，应用程序池：TargetAppPool（我的身份，.net 4））

我在DefaultWebSite上有一个重写规则（按照上的指示创建），它将所有本地主机（端口80）流量重定向到localhost:8085，正如上面的链接中所述。这适用于大多数文档类型（.aspx、.xap、.htm、.ico），但对MyService.svc的请求失败。它返回一个404

要明确的是：

当我将localhost:8085/MyService.svc粘贴到浏览器中时，我会得到请求的WCF页面

当我将localhost/MyService.svc粘贴到浏览器中时，我得到一个404

当我粘贴localhost:8085/MyIcon.ico到浏览器中时，我得到了请求的资源

当我将localhost/MyIcon.ico粘贴到浏览器中时，我会得到请求的资源

.svc是我发现的唯一返回404的文档类型

我有两条信息可能是相关的

应用程序池。当我将DefaultWebSite的应用程序池更改为TargetAppPool时，404将变为500（“未能映射路径“/”）。进行此更改时，所有其他请求均成功。不确定这是否相关

FREB（请求跟踪失败）日志。我发现了一个页面（），其中详细说明了当URL重写比我的更成功时（稍后失败），FREB日志中的步骤。我无法找到如何为成功重写生成FREB日志（如果可能的话），因此我只能将我的FREB日志与该博客上的日志进行比较。我可以在我的FREB日志中看到他们的第21步（URL更改），而不是第22步（URL重写结束）。我对这些日志没有足够的经验，没有注意到比这更重要的事情（欢迎建议）

我的主要问题是：有人知道为什么只是请求.svc资源的URL没有被重写吗

第二个问题是：是否有人知道如何为成功的请求生成FREB日志（如果可能的话）

谢谢

更新：

我已经改变了架构，试图获得更多信息

我已将目标网站移动到另一台电脑上，并在该电脑上安装了Microsoft Network Monitor以捕获传入流量

在我改变url重写规则指向这个新网站之前，当我在新电脑上向MyService.svc发出请求时，我得到了正确的响应。很好

一旦我更改了重写规则，将请求路由到新的目标网站，它就会像以前一样响应（404）。我已经发出了POST和GET请求。网络监视器日志中没有任何请求的迹象（所有其他呼叫-200、404或其他-都显示在此日志中）

---

这让我觉得url重写和*.svc请求不兼容。我尝试向MyService.asmx发出请求（创建了此文件），但它正确地返回了一个页面，因此它仅限于*.svc。有什么想法吗？

因为重写似乎适用于所有资源，但扩展名为时除外。svc我想说这将是重点关注的领域

我可以想象，这些资源与您的其他资源相匹配，但与您的服务不匹配，因为这些资源通常（通常很复杂），所以我认为值得测试您在URL中找到的任何规则。有关如何查找URL重写的正则表达式的详细信息

---

同样值得一看的是，任何具有相同心态的出站规则。

解决方案在目标网站的配置文件中

在web.config（在目标应用程序中）中，有一节内容如下：

我将此更改为：

---

这必须归功于（尽管他/她声称需要更改的是代理的配置，但我发现它是目标应用程序，而不是代理服务器）。

如果您仍然无法运行它，请确保网站上没有充当反向代理的WCF处理程序。 我通过添加反向代理的web.config禁用了此功能：

 <system.webServer>    
  ...
 <handlers>
  <remove name="svc-ISAPI-4.0_64bit" />
  <remove name="svc-ISAPI-4.0_32bit" />
  <remove name="svc-Integrated-4.0" />
 </handlers>
</system.webServer>

...

当我最初发布重写规则时，正则表达式是默认的（/.X），所以我认为这不是问题所在。[X=asterisk]此后我所做的是更改重写规则，使其与XMyService.X的通配符模式（而不是regex）匹配。现在，对MyService.htm、MyService.aaa和MyService.zzz的调用被重写到我为测试规则而设置的页面。但是对MyService.svc的调用继续返回404。有趣的是，调用DoesNotExist.htm（不在新规则的范围内）会返回一个不同样式的404页面（比MyService.svc显示的更详细）。表示“即使您要在IIS中添加.SVC处理程序并以与执行.HTM请求相同的方式重定向它，重定向也不会保留消息体。因此，对SiteB上的服务方法的请求不一定与SiteA上的服务方法调用相同”。我问过那张海报，他/她是否有这方面的参考资料，因为这可以解释我所看到的。你知道重定向是通过HTTP 302实现的吗？或者它们完全在服务器上处理（即对客户端透明）。如果正在使用302，您将能够使用Fiddler查看实际重定向，并能够验证主体是否确实被篡改。它完全在服务器上。Fiddler的输出中只有一个404（除了在我的OP中，当我更改AppPool时，它显示了一个500）。我遇到了同样的问题，我使用我的Port80网站代理webservice请求