問題タブ [reverse-proxy]

For questions regarding programming in ECMAScript (JavaScript/JS) and its various dialects/implementations (excluding ActionScript). Note JavaScript is NOT the same as Java! Please include all relevant tags on your question; e.g., [node.js], [jquery], [json], [reactjs], [angular], [ember.js], [vue.js], [typescript], [svelte], etc.

0 投票する
3 に答える
2575 参照

php - Apache: 別のサーバーから PHP を処理するためのリバース プロキシ

私は次の設定をしています:

  • Plain-Server : PHP ファイルをプレーンテキストとして配信する
  • Proxy-Server : Plain-Server に php ファイルを要求して解析します。

ここで私の質問: Proxy-Server (PHP 5.3 を使用した完全に構成可能な apache 2.2) を構成して、Plain-Server からプレーンな php ファイルを解釈するにはどうすればよいですか?

例: Plain-Server に小さな php スクリプト "hello.php" がある場合 (アクセス可能な throw http://plainserver/hello.php ):

Plain-Server はそれをプレーンテキストとして出力するだけで、php-code を解析しません。

Proxy-Server にファイル「hello.php」が存在しません。ただし、Proxy-Server から hello.php をリクエストする場合、mod_proxy (リバース プロキシ) を使用して Plain-Server から hello.php を取得する必要があります。また、「Hello World」だけを言って、php を解析して実行する必要があります。

リバース プロキシは既に実行されていますが、php コードの実行が機能していません。mod_filter を試しましたが、うまくいきませんでした。その方法はありますか?

0 投票する
1 に答える
807 参照

windows - PURGEをサポートするIISキャッシュ

Unixでは、通常、アプリケーションサーバーの前のVarnishの前にnginxをデプロイします。ここでは、nginxとVarnishの両方がリバースプロキシとして機能しています。Varnishはキャッシュを維持し、If-Modified-Since、Cache-Control応答ヘッダー、アプリケーションからのPURGE要求などをサポートします。nginxは多くの接続を受信するのが得意です。また、静的コンテンツを提供したり、gzip圧縮を有効にしたりするためにも使用します。

Windowsでは、IISの前でSquidを使用して管理できます。(Python)アプリケーションをISAPIワイルドカードフィルターとして(isapi-wsgiパッケージを使用して)展開することを計画しているため、アプリケーションはIISによって管理されるスレッドプールに存在します。

ただし、WindowsでのSquidの開発は停滞しているようです。ディスクから直接特定のものを提供できるように、IISをポート80のままにしておくことをお勧めします。また、IISは、Windows上のSquidよりも多くの接続を処理する際の回復力が高いと思います。

人々はここで通常何を使用しますか?1つのオプションは、IISの前で別の独立したキャッシングプロキシを使用することです。もう1つのオプションは、ISAPIフィルターとしてインストールされたもので、リクエストをインターセプトし、If-Modified-Since、画像やその他のキャッシュリソースの要求、アプリケーションからのPURGEリクエストなどに応答します。

そのようなものは存在しますか?または、SquidとMS ISA(高すぎる)の唯一の本当の選択肢です。

乾杯、マーティン

0 投票する
4 に答える
2803 参照

svn - Subversion のリバース プロキシとしての IIS7 および ARR

IIS7 と Application Request Routing 拡張機能を使用して、Apache で実行されている Subversion へのリバース プロキシとして機能しています。

プロキシは正常に動作し、サーバーを探索したり、「チェックアウト」を実行したりできます。ただし、通常は ASP.NET で禁止されているファイル (.cs、.csproj など) を参照できません。ASP.NET が関係しないファイル (.txt など) は問題ありません。

グローバルな web.config を編集して、これらのファイルの Forbidden ハンドラー マッピングを削除しようとしましたが、違いはないようです。すべてのファイル拡張子をレンダリングできるようにしながら、IIS7 の URL 書き換えモジュールを機能させる方法はありますか?

0 投票する
1 に答える
12033 参照

iis-7 - SSLを使用したIIS7リバースプロキシ?

どのIIS7ISAPIフィルターがそれを行うのに役立ちますか:

http://site1.domain1.com:80 ==>内部IISサーバー1(HTTP、TCP 80)

https://site2.domain1.com:443 ==>内部IISサーバー1(HTTPS、TCP 443)

http://site1.domain2.com:80 ==>内部IISサーバー2(HTTP、TCP 80)

http://site2.domain2.com:443 ==>内部IISサーバー2(HTTPS、TCP 443)

http://site1.domain3.com:80 ==>内部IISサーバー2(HTTP、TCP 8080)

http://site2.domain3.com:443 ==>内部IISサーバー2(HTTPS、TCP 8443)

0 投票する
7 に答える
11223 参照

gwt - リバース プロキシの背後にある GWT の問題 - nginx または apache

GWT がリバース プロキシの背後にある場合、GWT でこの問題が発生します。バックエンド アプリはコンテキスト内にデプロイされます。これを /context と呼びましょう。

直接ヒットすると、GWT アプリは正常に動作します。

http://ホスト:8080/context/

その前にリバース プロキシを構成できます。これが私のnginxの例です:

しかし、リバース プロキシを介して実行すると、GWT は次のように混乱します。

言い換えれば、GWT は /context/ を前に追加して C7F5ECA5E3C10B453290DE47D3BE0F0E.gwt.rpc を探す必要があるという言葉を受け取っていませんが、それは要求がプロキシ経由で来た場合のみです。回避策は、Web サイトの URL にコンテキストを追加することです。

しかし、これはコンテキストがユーザーに表示される URL の一部になっていることを意味し、これは醜いことです。

この場合、GWTを幸せにする方法を知っている人はいますか?

ソフトウェア バージョン:
GWT - 1.7.0 (1.7.1 と同じ問題)
Jetty - 6.1.21 (ただし、Tomcat にも同じ問題が存在)
nginx - 0.7.62 (Apache 2.x にも同じ問題)

DonsProxyを使用してプロキシとバックエンドの間のトラフィックを確認しましたが、特筆すべき点はありません。

0 投票する
1 に答える
1326 参照

apache - Tomcats (apache-tomcat クラスター内) を背後の apache サーバーへのリバース プロキシとして使用する

コンテンツを検索して提供する小さな Web サービス (コンテンツ サーバーなど) を作成しています。基本的に、これには 2 つの部分があります。1 つの動的部分は、クライアント認証を実行し、コンテンツに対して検索機能を提供します。2 番目の部分では、認証されたクライアントに静的コンテンツを提供します。

パフォーマンスとスケーラビリティの観点から、上記のサービスに適したアーキテクチャはどれですか?

  1. アプリケーションサーバー(Tomcat)を使用して両方を行うだけですか?
  2. しかし、コンテンツの圧縮などの簡単に構成可能なオプションを備えた静的コンテンツの提供には、apache の方が優れていると聞いています。では、Tomcat をリバース プロキシ (j2ep、noodle などを使用) として使用して、背後にある Web サーバーを apache するのはどうですか。背後にある apache サーバーがコンテンツを提供している間に、Tomcat は認証と検索を行うことができます。
  3. しかし、Tomcat は単一の連絡先であるため、パフォーマンスのボトルネックになる可能性があります。では、Apache Tomcat クラスタリングを再度使用して、セットアップ全体の負荷を分散してみませんか?

基本的に、各Tomcatが一連のApacheサーバーの背後にあるリバースプロキシとして機能するApache-Tomcatクラスターを見ています。この設定は可能ですか?誰もこれをやったことがありますか?私はこれを検索しましたが、ポインタを見つけることができませんでした。可能であれば、このアーキテクチャに潜在的な欠点はありますか?

それが悪いオプションである場合、この Web サービスの正しい方法は何ですか?

0 投票する
1 に答える
15183 参照

apache2 - Apache 2.2 リバース プロキシが機能しない

Apache (バージョン 2.2.3) をリバース プロキシとして機能するように設定しようとしています。で説明されているように、パブリックサーバーでApacheを構成しましたhttp://www.askapache.com/htaccess/reverse-proxy-apache.html

internal1 は、ローカル ネットワーク内の他のサーバーです。

ホームページ (www.example.com/app1/) は正しく表示されますが、内部サーバーがリダイレクトを行うときに問題が発生します。この場合、ブラウザ (Firefox 3.5.3 または Internet Explorer 7) は、ローカル ネットワーク (internal1.example.com/page1/) でアドレスを検索します。ProxyPassReverse ディレクティブが apache によって無視されているようです。

0 投票する
1 に答える
2320 参照

apache2 - Apache2を使用したリバースプロキシが機能しない

Apache / 2.2.8(Ubuntu)を使用していますが、問題があります。次のファイル/etc/ apache2 / sites-available/backuppcがあります。

これは192.168.134.10で実行されます。ブラウザ(FF)では、アドレスhttp:// localhost / BackupPcは目的のサーバーに移動しますが、アドレス行はhttp://192.168.134.59/backuppc/で表示されます。これは、このProxyPassがDNSサーバーのように機能するように感じます...最後にインターネットからは192.168.134.10のみに到達でき、/ backuppcを使用してログインを取得しますが、目的のサーバーにアクセスできます。

助けてください、THX。

平和

0 投票する
1 に答える
1526 参照

apache - CakePHP のリバース プロキシ?

CakePHP アプリケーションがあり、httpd.conf に次のディレクティブがあります。

CakePHP がなくても、これは問題なく動作します。ただし、CakePHP は routes.php やその他のソースからの独自のリダイレクト ロジックを使用しているため、プロキシ設定をオーバーライドしているように見えるため、サーバー上の「/community」への呼び出しは、 CommunityController と呼ばれるコントローラー。

ここでの私の問題は、複数のアプリケーションを提供する 1 つのサーバーを持ちたいが、それをユーザーに対してシームレスに保ちたいということです。そのため、完全な PHPBB アプリケーションは、たとえば「/forum」ディレクトリ内で、CakePHP のコントローラーであるかのように実行できます。

誰かがこれを以前に行ったことがありますか?それは可能ですか? mod_rewriteand/or routes.php ファイルがディレクティブをオーバーライドするのはなぜmod_proxyですか??

0 投票する
1 に答える
3016 参照

apache2 - 動的バックエンドサーバーでApache2リバースプロキシを設定するにはどうすればよいですか。

名前ベースの仮想ホストを使用してApache2をリバースプロキシとして設定し、リクエストをバックエンドサーバーにルーティングする方法を決定したいと思います。十分に単純です。

問題は、これらのバックエンドサーバーが動的に追加および削除される可能性があることです。私の最初のアイデアは、Apache構成ファイルをプログラムで書き直しapachectl graceful、バックエンドサーバーが起動または停止するたびに呼び出すことでした。これは正しい解決策のようには思えません。これを達成するためのより良い方法は何ですか?

名前の処理を別のバックエンドサーバーに適切に転送できる必要があります。たとえば、Backend-Server-Aがexample.comのリクエストを処理している可能性があります。監視プロセスにより、Backend-Server-Aが古くなっていると判断される場合があります(メモリ使用量が多すぎる、example.comを処理するための新しいバージョンのサーバーコードがあるなど)。監視プロセスはBackend-Server-Bを開始し、example.comのリクエストをまもなく処理します。Apacheは、example.comなどの新しいリクエストをBackend-Server-Bに送信する必要がありますが、Backend-Server-Aが現在処理されている保留中のリクエストは、Backend-Server-Aがシャットダウンされる前に完了できるようにします。

更新サーバー障害に投稿