自己ホスト型の WCF サービスと、同じマシンで実行する必要がある ASP .Net Web サイトがあります。自己ホスト型サービスが実行されている場合、IIS 向けのポート 443 へのすべての呼び出し (IP およびホスト ヘッダー/SSL バインディングに基づく) が WCF アーキテクチャにルーティングされるため、自己がホストされたサービスが実行されています。それは、IIS がその仕事をする能力を事実上横取りしています。
IIS は、ポート 80 などの他のポートでも正常に動作することに注意してください。ポート 443 では過熱しています。これがサーバーの問題なのか、コード/wcf の問題なのかは完全にはわかりません。
かなりの調査の結果、サービス エンドポイントの 1 つである crossdomain.xml ファイルをシミュレートするように設定された REST エンドポイントが IIS をプリエンプトしていることを突き止めました。そうでなければ、すべてが期待どおりに機能していました。私はそのエンドポイントを捨て、代わりに IIS を使用してファイルを提供しました。
ご想像のとおり、自己ホスト型サービスは、ポート 443 への呼び出しを IIS が取得する前に傍受しているようです。IIS ログを簡単に確認すると、これが起こっているかどうかを確認できます。
ポート 80 で複数のドメインを実行できますが、私の記憶が正しければ、ポート 443 では 1 つのみしか使用できないことに注意してください。そのため、ホスト ヘッダーなどは HTTPS 接続では機能しません。これも問題の一因となっている可能性があります。
代わりに IIS を介してセルフホステッド サービスをホストする方法はありますか? これにより、この問題が解決され、将来の管理負担が軽減される可能性があります。
次のコメントを編集します。IIS でホストできない場合は、WCF サービスが IIS の要求をインターセプトしていて、それがトラフィックの通過を妨げていることが正しいと仮定すると、何かを追加する必要があるかもしれません。 WCF アプリケーションを作成するか、HttpListener に基づいて受信トラフィック用の独立したプロキシを作成 (または既存の例を検索) し、それを使用して、探しているサービス要求を識別し、適切に中継します。もちろん、このタイプのプロキシ サービスを使用して拡張機能をマスクすることもできるため、それを使用して任意の形式の外部 URL を適切な内部サービス URL にリレーできます。重要なことは、プロキシがネットワーク スタック内で WCF と IIS の両方の前に位置するため、要求がどちらかによって取得される前にインターセプトできることです。自分で書くならHttpListenerはおそらく良い出発点になるでしょう。