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 より
Launching nginScript and Looking Ahead - NGINX
Analytics cookies are off for visitors from the UK or EEA unless they click Accept or submit a form on nginx.com. They’re on by default for everybody else. Follow the instructions here to deactivate analytics cookies. This deactivation will work even if you later click Accept or submit a form. Check this box so we and our advertising and social media partners can use cookies on nginx.com to better
Nginx導入時やること - Qiita
HTTPレスポンスヘッダにサーバのバージョンの表示を消す なぜ必要？ 潜在攻撃者への情報提供になることも。 もし使用中バージョンの脆弱性が明らかになった時、恰好の標的になるとか。 対応 nginx.confのhttpディレクティブに server_tokens off; を追加。
Nginxのパフォーマンスを極限にするための考察 - Qiita
ピクセルトラッキングを想定した設定で、Nginx on EC2(c3.large) という環境で、極限まで設定をして、どれぐらいさばけるのか運用中、パフォーマンステストしてる時は、別のところに問題があり、Nginx自体の性能限界までテストできなかったので、実際どこまでいけるのかは計測できてない。 秒間1万とか2万は行けてたと思う、ちなみに実際の運用では秒間9000以上とかを記録していて、サーバ自体にはかなり余裕があるので、記録はまだまだ伸びると思う。 ちなみに empty_gif は応答が短すぎて、Nginx の $request_time では記録できない... 全部 "0.000" だから、どれぐらい掛かってるのか分からん...。 nginx.confの設定 user nginx; worker_processes auto; error_log /var/log/nginx/erro
nginx の worker_connections は worker 当たりの同時接続数だと思ってたけどどうも違うっぽい - noob
※2014-12-18 追記※ はてブとかtwitterがついててちょっとビックリしてます． そしてtwitterで貴重なご意見をいただきました． 1024以下でもう少し増やすとどうなるかなぁ。workerに偏りがあってエラー出てるのかも。例えば8*768とか。 / “nginx の worker_connections は worker 当たりの同時接続数だと思ってたけどど…” http://t.co/5aLNa0VeOy— MATSUMOTO, Ryosuke (@matsumotory) 2014, 12月 16 なるほどー． ということでworker_processes 8, worker_connections 768でざっくりですが早速試してみました． 結果，worker_connections are not enoughエラーは見られなくなったように思います． # というの
Pitfalls and Common Mistakes | NGINX
Analytics cookies are off for visitors from the UK or EEA unless they click Accept or submit a form on nginx.com. They’re on by default for everybody else. Follow the instructions here to deactivate analytics cookies. This deactivation will work even if you later click Accept or submit a form. Check this box so we and our advertising and social media partners can use cookies on nginx.com to better
SSL 3.0 を無効に設定する方法(POODLE対応) apache+mod_ssl, nginx - Qiita
SSL 3.0の脆弱性 CVE-2014-3566 aka POODLE の対応でSSL v3を無効にする必要あり http://www.itmedia.co.jp/news/articles/1410/15/news054.html http://googleonlinesecurity.blogspot.jp/2014/10/this-poodle-bites-exploiting-ssl-30.html https://blog.mozilla.org/security/2014/10/14/the-poodle-attack-and-the-end-of-ssl-3-0/ https://www.openssl.org/~bodo/ssl-poodle.pdf Apache httpd + mod_sslなら http://httpd.apache.org/docs/2.2/mod
キャッシュエンジンの比較（1/3） | IIJの技術 | インターネットイニシアティブ（IIJ）
大規模なサイトでは、クライアントからのアクセスを効率よく受け付けるためにオリジナルのコンテンツを保持するオリジンサーバのほかに、何らかのリバースプロキシも運用してコンテンツの配信をしています。まず、ここではリバースプロキシとして利用できるプロダクトの中からコンテンツキャッシュの機能（キャッシュサーバ）について説明します。 キャッシュサーバに期待される役割 コンテンツを配信する上で、キャッシュサーバには以下のような役割が期待されています。 コンテンツをキャッシュデータとして保持すること キャッシュデータを管理すること オリジンサーバへの問い合わせを減らすといった負荷分散をすること 大抵のキャッシュサーバでは、キャッシュしているコンテンツを有効期限（Time To Live : TTL）付きのキャッシュオブジェクトとして保持していますが、TTLを無視してキャッシュオブジェクトの更新をしたい、と
NginxでリバースプロキシをKeepAliveしたときの性能検証 - Qiita
Nginx + Luaを用いた、ハイパフォーマンスで動的なプロキシサーバを考察中です。 そのための施策の一つとして 上流サーバへのアクセスをKeepAliveする という方法がありますが その際、プロキシサーバにどの程度性能に変化があるのかを調査してみました。 リバースプロキシのkeepalive設定 前提条件として Nginx > 1.1.4 が必要。 upstreamに keepalive というattributeがあるのでそれを設定します。 それと同時に、プロキシヘッダーにHTTP/1.1設定などを行いましょう。 ちなみにproxy_passだけだとkeepaliveできないようです。upstream必須。 あと、もちろんバックエンドサーバ側もkeepalive設定しておきます。 upstream http_backend { server oreore.micro.service;
Reverse Proxy がなぜ必要か - naoyaのはてなダイアリー
フロントエンジニアに知ってもらいたいリバースプロキシの重要性 | RickyNews この記事が目に入って読んでみた。なるほど、昨今は Reverse Proxy は便利な L7 ルーター的なものとして認識されているのだな、と思った。URL の Rewrite や、VirtualHost 云々。確かに Reverse Proxy の便利な側面ではある一方、それらは Nginx などの Reverse Proxy でなければ実装が不可能かと言えばそんなことはないものでもある。 自分は Reverse Proxy はもうすこしサーバー/インフラ的な側面でその役割を捉えている。今更何をというものでもあるが、昼休みがてら時間があるので簡単に書いてみよう。 Reverse Proxy はWebシステム全体のリソース最適化のためのパーツ Reverse Proxy のインフラ的な視点での役割は「Web
'mod_small_lightのNginx版ngx_small_lightをつくってみた' - bokko bokkoにしてやんよ
https://github.com/cubicdaiya/ngx_small_light サムネイルの動的生成を行うApacheモジュールのmod_small_lightをNginxにポーティングしてみた。 nginx.confはこんな感じで、できるだけmod_small_lightとあえて同じようにパラメータを指定できる形にしてある。 なのでパラメータの詳細についてはmod_small_lightの公式解説ページを参考にするとよい。 server { listen 8000; server_name localhost; # small_lightを有効にする small_light on; # 変換パターンを定義 small_light_pattern_define msize dw=500,dh=500,da=l,q=95,e=imagemagick,jpeghint=y; sma
nginxで既存のHTTPヘッダーを上書きして送出する方法 | ykzts.blog
nginxで任意のHTTPヘッダーを追加したい場合にはadd_headerディレクティブを用いますが、add_headerディレクティブは追加しようとしたフィールド名が重複するHTTPヘッダーが既に用意されていた場合には既にある物に「,」区切りで連結してしまいます。たとえば強制的に出力するContent-Typeを変更するためにadd_header Content-Type text/css;のようにしてもContent-Type: text/html, text/cssといった形の不正なHTTPヘッダーが出力されてしまいます。 解決方法は簡単でHTTP Headers More Moduleのmore_set_headersディレクティブをつかえばすぐです。使い方も簡単でadd_headerディレクティブをつかっている箇所をそのままmore_set_headers "Content-Ty
Nginxで静的ファイルをPOSTで取れない - pullphone's blog
htmlファイルやtxtファイルといったAPサーバーに送らず、Nginxが自ら処理するアクセスをPOSTで取ろうとすると405エラーを返すという挙動になっているようです。 通常のブラウザアクセスではほぼ起こり得ないパターンですが、ネイティブアプリ向けAPIを作っていてクライアント側が全部のアクセスをPOSTで送ってきたりなんかするときはあるかもしれません（実際、僕が遭遇したパターンはこれです）。 解決法としては2つあります。 設定ファイルで何とかする ソースコードを変更する (1.)は、つまり405で来たものを無理やり元のuriにして戻すという手法ですね。 以下の一行をserverディレクティブの中に入れてやるだけでOKです。 error_page 405 = $uri;ただ、個人的に(1.)の方法はどうなんかなーと思ったので(2.)のように元から断つことにしました。 問題の箇所はsrc/
does nginx support compress the request to the upstream?
Dose nginx supprt this ? Whoul you please show me some configuration of it? [Client] [Nginx Reverse Proxy] [BackEnd] | [Raw Post] | [gzip encoded request] | |--------------------> | ----------------------------->| | | | | [Raw Response] | [gzip encoded response] | | <------------------ | <-----------------------------| | | |
高速・軽量・高機能……Nginxの基礎知識
処理能力の高さなどを理由に、近年、大規模サイトを中心に急速にシェアを拡大しているWebサーバー「Nginx」。この連載では、その特徴と魅力を分かりやすく紹介します。 第3のWebサーバーとして注目を集めるNginx 1日に数億リクエストを処理するような大規模サイトを中心に、近年急速にシェアを拡大しているWebサーバーが「Nginx（エンジンエックス）」です。HTMLドキュメントや画像ファイルといった静的コンテンツを高速で配信し、消費メモリが少なく、リバースProxyやロードバランサーといった機能も有した注目の軽量Webサーバーです。ネットクラフト社の調査によると、2014年6月時点でApache HTTP、Microsoft IISに次ぐ第3位のシェアを獲得しています。 依然としてApache HTTPやMicrosoft IISのシェアは高いものの、Nginxの認知度は日に日に高くなって
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
nginxのパフォーマンスチューニング
画像変換Night - 資料一覧 - connpass
TechCrunch | Startup and Technology News
Bitbucket | The Git solution for professional teams
Nginx入門 松江高専2014年度テキスト