nginxで unix ドメイン socket をlisten してバックエンド専用に設定する。 - それマグで！
nginx 使いまくり問題 docker やCDNとか使ってると、いくつのプロキシが挟まるんだよ。管理面倒くさいんだよ。って問題にぶち当たる。特にphp 関連。 browser → 企業・学校内プロキシ → CDN → docker ホスト nginx → dockerコンテナnginx → php-fpm コレ全部が、SSLのデクリプトとエンクリプションや、TCPコネクションでsyn/ack してると思うとゾッとしない話ではない。そりゃhttp2でTCP節約が必要になるよねって感じる。 リバースプロキシから裏側はTCPを減らせるのでは。 docker ホスト nginx → dockerコンテナnginx → php-fpm この部分がlocalhost:9000とかで待ち受けてるけど、全部unix ドメインソケットにしてしまえば、接続も管理も楽になるんじゃないかと。 nginx が u
【図解/apache】MPM prefork/worker /event (イベント駆動)の違い～CPUコアの使い方～
Apache の MPM とはApache サービスを起動すると、httpd プロセスが複数生成されます。 各プロセスはクライアントからの http リクエストを受け付け、処理を行いクライアントへレスポンスを返します。 プロセスを複数生成することで同時にリクエストを処理することができるようになります。これを実現するモジュール（追加機能）のことを Multi Processing Module , 略して MPM と呼びます。 MPM には 3 つの方式が存在します。prefork / worker / event driven (イベント駆動) です。 以降でこれらの違いを解説していきますが、prefork と worker の違いをより理解するためには、プログラム（プロセス）が CPU をどのように使っているのかを知る必要があります。以下の記事に概要を解説していますので併せてご参照下さい
Nginxでproxy_passにホスト名を書いた時の名前解決のタイミング - （ひ）メモ
Nginx 1.4.2で試しました。 ネームサーバーは、ローカルのunboundをlocal-zone, local-dataを使って簡易コンテンツサーバーにして試しました。 local-zone: "oreno." static local-data: "api.oreno. 30 IN A 192.0.2.11" # local-data: "api.oreno. 30 IN A 192.0.2.12" proxy_passにホスト名を書くと→名前解決は一度だけ このように Nginx の設定を書いた場合、 location /api { proxy_pass http://api.oreno:9999; } 「api.oreno」の名前解決は、nginxの起動時に行われます 名前解決できない場合は、nginxは起動しません 名前解決できた場合は、ずっとそのIPアドレスにreverse
nginxでproxy_passのtrailing slashには特に気をつけるべきという話
以前お話したtrailing slashについて。 http://blog.cosnomi.com/archives/475 意味上の違いはあるけど、実質あまり気にしなくても大丈夫だよねという感じだった。しかし、nginxの設定をしていると見事にハマったのでメモとして残しておきたい。 今回、比較するのは以下のCase1とCase2。 実際どうなるか Case1: Trailing Slash あり http://example.com/japan/hoge にアクセスした場合、proxy_passによってhttp://example.jp/hoge に転送される。http://example.com/japan/ へのアクセスは http://example.jp/ に転送されるはず。 example.jp側ではわざわざ/japanを含めて処理してやる必要がないので、こちらのほうが適切っぽ
nginx.conf の location の優先順位を正しく理解する - 無印吉澤
最近、Nginx の location 設定の優先順位を誤解していて軽くつまづきました。このへん時々よくわからなくなるので、自分のためにまとめておきます。 情報源 公式の説明は、マニュアルの Module ngx_http_core_module ページ内の "location" の項にあります。 nginx.org location の修飾子(modifier) location を定義する際に使える修飾子は、以下の5種類です。 修飾子 判定方法 = 完全一致 なし 前方一致 ^~ 前方一致 ~* 正規表現（case-insensitive） ~ 正規表現（case-sensitive） 前方一致が2種類ありますが、これは「^~ は省略可能」という意味ではありません。 location の優先順位 location の優先順位を考える上でややこしい点は、書かれた順に評価される設定と、最長
Nginxでlocationの書き方はとりあえずコレにしておけ - Panda Noir
「Nginx の location の書き方がわからない！」そう思ったことはありませんか？ ネストするとおかしくなる 同じ階層にあるうち一つしか適用されない 同じ階層のlocationディレクティブの演算子をすべてチェックしないと、どれが適用されるかわからない このように、Nginx の locationディレクティブは直感的ではなく、クセのある動作をします。 今回はとてもカンタンで、ファイル分割管理が楽になるやり方をご紹介します。 locationの基礎事項 まずlocationの基礎知識ですが、locationは並列して書かれていた場合、どれか一つのみ適用されます。どれが適用されるかは演算子によります。 「=、^~、~、~*、なし」の順に適用されます。 =完全一致 ^~前方一致~case-sensitive*1な正規表現 ~*case-insensitive*2な正規表現 なし前方一致
Nginxのlocationとproxy_passの末尾スラッシュによる挙動の違いを理解する
これに対し、4パターンのリクエストを投げて実験を行った。 http://example.com/path http://example.com/path/ http://example.com/path-test http://example.com/path/test 末尾スラッシュ（Trailing Slash）による挙動の違い 結論から先にまとめる。 location locationの末尾スラッシュがない場合は前方一致、ある場合はURIの完全一致になる。 結果は以下のとおり。 location /path http://example.com/path → OK http://example.com/path/ → OK http://example.com/path-test → OK location /path/ http://example.com/path → 301 M
[雑記] nginx の proxy_set_header の扱い
proxy_set_header の動きがちょっとおかしいなと思ったのでメモ。 バージョン nginx 1.2.6 リバースプロキシを使う際、下記のような感じで、お決まりの proxy_set_header を http コンテキストで設定しておくと思います。 http { proxy_redirect off; proxy_set_header Host $host; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Host $host; proxy_set_header X-Forwarded-Server $host; proxy_set_header X-Real-IP $remote_addr; upstream backend { server 1
![[雑記] nginx の proxy_set_header の扱い](https://cdn-ak-scissors.b.st-hatena.com/image/square/0595b70c8a16e82444d7ea693954865e652ab7ea/height=288;version=1;width=512/https%3A%2F%2Fblog.kteru.net%2Fcontent%2Fimages%2F2014%2FMar%2Ficon.jpg)
nginxの設定ミスで起こるSSRF - Qiita
はじめに この記事は下記リンクの日本語翻訳記事です 翻訳が誤っている場合はコメントか@no1zy_secまでお知らせいただけると幸いです。 [SSRF] Server Side Request Forgery Server Side Request Forgeryはサーバーに任意のリクエストの実行を強制する攻撃です。例えばnginxの場合、proxy_passディレクティブの第2引数を攻撃者が指定できる場合に攻撃が可能になります。 どうやって見つけるか ここにサーバーを脆弱にする2種類のエラーがあります。 internalディレクティブの欠如。 これは内部リクエストにのみ使うことができることを示すために使用されます 安全でない内部リダイレクト internalディレクティブの欠如 internalディレクティブの欠如でSSRFをすることができる典型的な設定ミスです。
NGINX Documentation
DevCentral Connect & learn in our hosted community MyF5 Your key to everything F5, including support, registration keys, and subscriptions NGINX Learn more about NGINX Open Source and read the community blog NGINX Product Documentation Learn how to deliver, manage, and protect your applications using F5 NGINX products.
nginx の設定をレビューするときの観点をまとめてみた - Cybozu Inside Out | サイボウズエンジニアのブログ
こんにちは。 インフラチームの野島（@nojima）です。 チームのメンバーに nginx の設定について気をつけるべき点を共有するために、レビュー観点を書きました。 せっかくなのでここで公開します。 ほとんどの項目は自分やチームのメンバーの実体験に基いています。 レビュー観点 server server_name が他のやつと被っていないか。 listen する IP アドレスが同じ場合、server_name で区別できないといけない。 TLS を使う場合、SNI をサポートしないクライアントでは TLS 用の設定が default_server のものが使われる点にも注意。 TLS を使う場合、listen ディレクティブに ssl オプションを書いているか。 location location のマッチの順番に注意 正規表現の location は前方一致の location より
Nginx設定のまとめ
はじめに 僕は盲目的にunicornを起動するためだけにnginxを使っていて、設定ファイルの内容とかをほとんど知らない。 なので、ここにnginxの設定内容をまとめる事で自分自身が覚えようと思う。 普段使う大抵の設定は記載しているつもりです。 記載内容は実際に試したものと試してないものが混在してるので、誤った設定などがあるかもしれないのでその辺はコメントでご指摘いただけると助かります。 インストール インストールについては僕が書くより他の人の記事を見た方がいいと思う。 centosに入れるなら以下の記事が参考になる。 CentOS6.xにてnginxの最新版をインストールする手順 CentOS 6.5でnginxを動かす為の最低限の設定 またchefでインストールする場合は以下の記事が役にたつ。 Chefでnginxを導入してみる ChefでNginxをインストールするときにハマった c
nginx入門
Kubernetesでの性能解析 ～なんとなく遅いからの脱却～ （Kubernetes Meetup Tokyo #33 発表資料） 2020/08/26 NTT DATA Yasuhiro Horiuchi
nginxのworkerプロセス数をCPUコア数の倍数で自動的に設定できるモジュールを書いた - 人間とウェブの未来
nginxはworkerプロセスの数をCPUコア（スレッド）数で決定するworker_processes autoという便利設定があります。 これが多用されているのは、nginxがノンブロッキングでリクエスト処理を行うため、コンテキストスイッチなどを考慮した場合に、コア数で立ち上げておけば効率よくCPUを使い切れるという前提があるからです。 一方で、例えば僕の用途では、現在画像の処理だったりとか、ngx_mrubyのようにリクエストの過程で一部ブロッキングされるような処理も増えてきているため、コア数以上の値に設定しておいた方が性能を発揮できるような状況も増えてきています。 そうなると、現状、非常に便利な設定であるauto設定を使えずに静的に数字を設定する必要があり、例えばサーバリプレース時には古いコア数を考慮した値になっていたりして、リプレース後にCPUのコア設定がそのままで性能が出せてい
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
NGINX caching proxy fails with SSL23_GET_SERVER_HELLO:sslv3 alert handshake failure
nginxでproxy_pass先にSNIなhttpsを指定する - Qiita
Nginx reverse proxy to Heroku fails SSL handshake
Forward Custom Header from Nginx Reverse Proxy
Nginx URL masking to a different domain
How can I config the ngix server in production instead of webpack-dev-server?