タグ付けされた質問 「nginx」

（ヒント：毎回ブラウザキャッシュをクリアする）nginxなどの単一のファイルを提供するのに何時間もかかった後、エイリアスディレクティブを使用する方法と、ルートディレクティブを使用する方法の2つの異なる方法を見つけました。robots.txt location /robots.txt { alias /home/www/static/robots.txt; } location /robots.txt { root /home/www/static/; } 2つの間に機能的な違いはありますか？またはセキュリティの問題？他のディレクティブとの競合はありますか？（両方とも別の/ staticロケーションで問題ないように見えました）。それとも、どちらかを選択する理由は何ですか？ 注-私は両方を同時に使用しませんでした :)むしろ、一度に1つずつ試し、両方とも機能しました。同じファイル内で両者がどのように相互作用するかを尋ねているわけではありませんが、どちらを使用する方がよいでしょうか。

66 nginx 

私がやりたいのは 誰かがhttp://localhost/route/abcサーバーのレスポンスにアクセスすると、http://localhost:9000/abc Nginxを次のように構成します。 location /route { proxy_pass http://127.0.0.1:9000; } httpリクエストは9000正しくポートにディスパッチされますが、受信したパスはhttp://localhost:9000/route/abcそうではありませんhttp://localhost:9000/abc。 なにか提案を ？

65 nginx 

Djangoアプリケーションをデプロイするときに、nginxをuWGSIと連携するように構成する方法に関するチュートリアルが多数あります。 しかし、なぜこのキットにnginxが必要なのですか？uWSGI自体はWSGI Pythonアプリケーションを提供でき、静的ファイルを提供でき、SSLも実行できます。nginxはuWSGIではできないことを何ができるのでしょうか？

62 nginx  django  uwsgi 

私はむしろ大きくて遅い（複雑なデータ、複雑なフロントエンド）のWebアプリケーションで構築していRoRとによって提供されるPumaとnginxのようにリバースプロキシを。見てみるとnginx、エラーログ、私は次のようにかなりの数のエントリを参照してください。 2014/04/08 09:46:08 [warn] 20058#0: *819237 an upstream response is buffered to a temporary file /var/lib/nginx/proxy/8/47/0000038478 while reading upstream, client: 5.144.169.242, server: engagement-console.foo.it, request: "GET /elements/pending?customer_id=2&page=2 HTTP/1.0", upstream: "http://unix:///home/deployer/apps/conversationflow/shared/sockets/puma.sock:/elements/pending?customer_id=2&page=2", host: "ec.reputationmonitor.it", referrer: "http://ec.foo.it/elements/pending?customer_id=2&page=3" 異なるユーザーや異なるユーザーインタラクションでページが同じままである可​​能性は非常に低いので、かなり興味があり、ディスク上の応答のバッファリングが必要/有用であるとは思わないでしょう。 私はproxy_max_temp_file_sizeそれを知っていて0に設定していますが、少し気まずいようです（私のプロキシはバッファリングしようとしますが、バッファリングするファイルがありません...どうすればもっと速くできますか？） 私の質問は： [警告]を削除して、応答のバッファリングを回避するにはどうすればよいですか？オフにするproxy_bufferingかproxy_max_temp_file_size、0 に設定する方が良いですか？どうして？ 場合nginxの応答をバッファリング：ときには、バッファへの応答、および理由を提供していますか？ なぜnginxなりproxy_buffering、デフォルトでオンにし、それが実際に応答をバッファリング場合S [警告]？ 応答がそのオプションをトリガーするのはいつですか？応答を提供するのに>数秒（何秒）かかりますか？これは構成可能ですか？ TIA、ngw。

61 nginx  reverse-proxy  buffer 

nginxのネストされた場所を理解するのに問題があります。いくつかの構成ディレクティブが共通する2つの場所があるため、ディレクティブを繰り返すのではなく、正規表現を使用してURIを繰り返したいと思います。 location ~ /a|/b { location /a { } location /b { } } ただし、これによりエラーが発生します nginx: [emerg] location "/a" is outside location "/a|/b" in /etc/nginx/nginx.conf:36 また|はなしでも大丈夫なようです。 location ~ /a { location /a { } } 何が間違っていますか？何も繰り返さずにこれを行うより良い方法はありますか？別の方法で場所をグループ化できますか？

60 nginx 

HTTPヘッダーのウィキペディアの説明X-Forwarded-Forは次のとおりです。 X-Forwarded-For：client1、proxy1、proxy2、... ディレクティブのnginxドキュメントにはreal_ip_header、次の部分があります。 このディレクティブは、置換IPアドレスの転送に使用されるヘッダーの名前を設定します。 X-Forwarded-Forの場合、このモジュールはX-Forwarded-Forヘッダーの最後の IPを置換に使用します。[エンファシス鉱山] これらの2つの説明は、相反するように見えます。このシナリオでは、X-Forwarded-Forヘッダーは説明したとおりです。クライアントの「実際の」IPアドレスは左端のエントリです。同様に、nginxの動作は、右端の値を使用することです。これは、明らかにプロキシサーバーの1つにすぎません。 私の理解でX-Real-IPは、プロキシではなく、実際のクライアントIPアドレスを決定するために使用されることになっています。私は何かを見逃していますか、これはnginxのバグですか？ そして、それを超えて、誰でも作る方法について何か提案していないX-Real-IPヘッダが表示され、左の定義によって示されるように、 -ほとんどの値はX-Forwarded-For？

59 nginx  reverse-proxy  http-headers 

私はnginxで2つのことを行うルールを作成したい： 「www」を削除します。リクエストURIから 要求URIが「http」の場合、「https」にリダイレクトします これらのそれぞれを個別に行う方法の例はたくさんありますが、両方を正しく実行する（つまり、リダイレクトループを作成せず、すべてのケースを適切に処理する）ソリューションを見つけることはできません。 これらのすべてのケースを処理する必要があります。 1. http://www.example.com/path 2. https://www.example.com/path 3. http://example.com/path 4. https://example.com/path これらはすべて、ループせずにhttps://example.com/path（＃4）で終わるはずです。何か案は？

57 nginx  ssl  https  rewrite 

nginx Webサーバーには2つのアクティブなブランチがあるようです。「メインライン」ブランチ（現在1.9.x）と「安定した」ブランチ（現在1.8.x）です。誰もがこれら2つのブランチの違いを説明する公式ソースを提供できますか？

54 nginx 

26Gbファイルをアップロードしていますが、次のような結果になります： 413 Request Entity Too Large これはに関連しているclient_max_body_sizeので、このパラメータをに設定してい30000Mます。 location /supercap { root /media/ss/synology_office/server_Seq-Cap/; index index.html; proxy_pass http://api/supercap; } location /supercap/pipe { client_max_body_size 30000M; client_body_buffer_size 200000k; proxy_pass http://api/supercap/pipe; client_body_temp_path /media/ss/synology_office/server_Seq-Cap/tmp_nginx; } しかし、ファイル全体がアップロードされると、このエラーが表示されます。

54 nginx 

NginxをMac OS Xにインストールしました（http://www.kevinworthington.com/nginx-mac-os-snow-leopard-2-minutes/に感謝します）が、Mac OS XでNginxを再起動するにはどうすればよいですか？ ありがとう！

52 mac-osx  nginx  mac 

CentOSで実行されているnginx / 0.7.68を次の構成で使用しています。 server { listen 80; server_name ***; index index.html index.htm index.php default.html default.htm default.php; location / { root /***; proxy_pass http://***:8888; index index.html index.htm; } # where *** is my variables これproxy_passは、IPが頻繁に変更されるDNSレコードに対するものです。Nginxは古いIPアドレスをキャッシュするため、誤ったIPアドレスへのリクエストが発生します。 IPアドレスが古くなった場合、nginxがIPアドレスをキャッシュしないようにするにはどうすればよいですか？

52 linux  nginx 

これは以前に尋ねられたと確信していますが、有効な解決策は見つかりません。 WebサイトはCMSサービスを切り替えましたが、同じドメインを持っています。単一ページのnginx書き換えを設定するにはどうすればよいですか？ 例えば 古いページ http://sitedomain.co.uk/content/unique-page-name 新しいページ http://sitedomain.co.uk/new-name/unique-page-name 注意してください、コンテンツページ内のすべてがリダイレクトされるのではなく、文字通り上記のURLだけがリダイレクトされます。設定するリダイレクトは約9個ありますが、そのうちどれもパターンに適合しません。 ありがとう！ 編集：私はこの解決策を見つけましたが、スラッシュなしでリダイレクトするという事実を除いて、動作しているようです： if ( $request_filename ~ content/unique-page-name/ ) { rewrite ^ http://sitedomain.co.uk/new-name/unique-page-name/? permanent; } しかし、これは次のものにリダイレクトされます。 http://sitedomain.co.uknew-name/unique-page-name/

51 nginx  rewrite 

なされてきたたくさんの話にセキュリティ上の問題に対して約nginxの（通常はPHP-FPM、ファストCGI）で使用するPHPオプション。 cgi.fix_pathinfo その結果、デフォルトのnginx設定ファイルは次のように言っていました： # NOTE: You should have "cgi.fix_pathinfo = 0;" in php.ini ただし、現在、「公式」のNginx wiki では、上記のPHPオプションを無効にせずにPATH_INFOを正しく処理できると述べています。だから何？ ご質問 何をするのか明確に説明できますcgi.fix_pathinfoか？（公式ドキュメントは、「PATH_INFOの詳細については、CGI仕様を参照してください」とだけ言っています） PHPは、これらPATH_INFOとSCRIPT_FILENAME変数を実際にどのように使用しますか Nginxでなぜそしてどのように危険なのでしょうか？（詳細な例） 問題はこれらのプログラムの最近のバージョンにまだ存在しますか？ Apacheは脆弱ですか？ 各ステップで問題を理解しようとしています。たとえば、php-fpm Unixソケットを使用するとこの問題を回避できる理由がわかりません。

51 nginx  security  php-fpm  fastcgi 

これらのすべてをフローで組み合わせることを推奨する人がいますが、多くの重複する機能があるようですので、実際のWebサーバーにアクセスする前に3つの異なるプログラムを通過させたい理由を掘り下げたいと思います。 nginx： ssl：はい 圧縮：はい キャッシュ：はい バックエンドプール：はい ワニス： ssl：no（トンネル？） 圧縮：？ キャッシュ：はい（主な機能） バックエンドプール：はい haproxy： ssl：no（トンネル） 圧縮：？ キャッシュ：いいえ バックエンドプール：はい（主な機能） 主な機能の利点の一部を得るためだけに、これらすべてをメインWebサーバーの前にチェーン化する意図はありますか？ 非常に多くのデーモンが同じようなことを一緒にストリームするのは非常に壊れやすいようです。 展開と注文の優先順位とその理由は何ですか？

50 nginx  web  haproxy  varnish 

大きなファイルをアップロードしようとするたびに、ログファイルに次のエラーが表示されます。 a client request body is buffered to a temporary file /var/lib/nginx/body/0000000001 ファイルは正常にアップロードされますが、常に上記のエラーが表示されます。 私は増加client_body_buffer_sizeし1000mたが、私はあることをアップロード最大のファイルを期待するものです。ただし、これは単なる推測であり、そのエラーはもう発生しませんが、これがclient_body_buffer_size？に設定する適切な値かどうか疑問に思っています。 誰もがこの指令とその使用方法に光を当てることができれば幸いです。

48 nginx