コンテンツキャッシュとVaryヘッダとnginx - Qiita
Varyヘッダは前段のキャッシュサーバに対して、指定したヘッダの内容ごとにキャッシュを分ける必要があることを伝えるためのものです。例えばサーバがVary: Accept-Encodingをレスポンスヘッダに付加しておくと、キャッシュサーバはAccept-Encodingヘッダの内容に応じたキャッシュを保持します。 こうすることでクライアントのAccept-Encodingヘッダの内容に応じたキャッシュデータをキャッシュサーバは返すことができるというわけです。 nginxにおけるgzip圧縮とVaryヘッダ さて、本題です。上記のような事情からかApacheのmod_deflateやh2oなんかはコンテンツのgzip圧縮を有効にすると、自動的にVary: Accept-Encodingをレスポンスヘッダに付加します。一方我らがnginxは設定ファイルにgzip_vary on;と書かないとV
News, Views, and How-Tos from NGINX, Inc. | NGINX
F5 Sites DevCentral Connect & learn in our hosted community F5 Labs The latest threat intel and research to help protect your apps MyF5 Your key to everything F5, including support, registration keys, and subscriptions Partner Central Research and support for partners LearnF5 Guidance, insights, and how to use F5 products Contact F5 Contact F5 Sales Talk to an F5 sales representative Contact F5 Su
NginxでのOCSP Stapling対応設定
意外にハマったのでメモ。 OCSPとは OCSP（Online Certificate Status Protocol）とは、SSL/TLS暗号化通信の初期フェーズにおいて証明書の失効を確認するための手順。 従来は署名所失効リスト(CRL)が利用されていたが、CRLはリストが肥大化しダウンロードに非常に時間がかかるようになってきたため、単一レコードの取得で済むOCSPが、現在では証明書の失効を確認する方法として一般的になった。 OCSP Staplingとは 通常は以下の図のように、証明書をダウンロードしたクライアントがOCSP Responderにサーバ証明書の失効を確認する。 OCSP Staplingに対応すると、以下の図のように証明書の失効確認をサーバ側で処理することができる。 また、OCSPレスポンスは一定の間はサーバにキャッシュされ、都度OCSP Responderに問い合わせ
mod_rewriteをnginxに移植するコツはifを使わないコト！
こんにちは。CTOの馬場です。 このエントリはnginxアドベントカレンダーの4日目です。 みんな大好き mod_rewrite をnginxに移植するコツをさらっと紹介します。 結論 まず server とか location を使おうとする try_files など他の方法がないか考える どうしてもどうしてもダメなら map と if を使う 以上！ コツは「とにかく if を使わない」ことです。 手続き的な書き方から宣言的な書き方に頭を切り替えるとうまく馴染めると思います。 例: wwwありでアクセスがきたらwwwなしに転送する server { listen 80; listen 443; server_name www.example.com; return 301 $scheme://example.com$request_uri; } rewrite 要りません。 例: サブ
[mruby][ruby] 30d.jp に ngx_mruby を導入した話, RubyPrize 2014 を受賞しました - HsbtDiary(2014-11-13)
■ [mruby][ruby] 30d.jp に ngx_mruby を導入した話 (社内で共有した内容の転記です) 30d.jp に ngx_mruby を導入して、誰も手出しができないミドルウェアの置き換えとパフォーマンス向上を実現しました。 前提要件 30d.jp に保存している画像はサービスにログインしている時のみ見えるようにしたい 画像は MogileFS に保存しており、Rails を介さないでレスポンスを返したい ngx_mruby 導入前のシステム構成 ngx_mruby 導入後のシステム構成 導入後の効果 siege を用いたベンチマーク(siege -b -c 8 -r 50)でレスポンスタイムで 1割ちょっと、転送レートで 2割ちょっとの改善となりました。 Elap Time, Resp Time, Trans Rate, Throughput, Concurrent
![[mruby][ruby] 30d.jp に ngx_mruby を導入した話, RubyPrize 2014 を受賞しました - HsbtDiary(2014-11-13)](https://cdn-ak-scissors.b.st-hatena.com/image/square/8cab6183abe73ade0ce0a24c302ac36ee5c17b43/height=288;version=1;width=512/https%3A%2F%2Fwww.hsbt.org%2Fdiary%2Ftheme%2Fogimage.png)
nginxで同じパスでPCとSPのページ出し分け（簡易版） - taiyoh's memorandum
今更ながら、nginxにmapという機能があることを知った。 → HttpMapModule ということで、以下のことを試してみた。serverブロックの外側に以下のような記述を追加してみる（中に書くと怒られる）。 map $http_user_agent $myindex { default /index.html; ~(iPhone|Android) /index_sp.html; } んで、serverブロックの中のlocationの指定で location / { root /path/to/document/root; index $myindex; } って感じでindexの値をmapで指定した値に変えておくと、UserAgentに「iPhone」とか「Android」って入ってればindex_sp.htmlをインデックスファイルに、そうでなければindex.htmlをインデッ
Nginxで特定のUserAgentからのアクセスを制限する - vmem.jp
2014-02-16 制限したいUserAgentが増えると管理が面倒。 Nginxの場合だと if ($http_user_agent ~ (ZmEu|VeryBadBot|MaliciousBot) { return 403; } で出来るのは知っているのだけど、これだと制限したいUserAgentを増えてくると管理が面倒。 map なんとかならんのかと思ったらmapディレクティブを使うとなんとかなった。 Module ngx_http_map_module map $http_user_agent $bot { default 0; ~*(zmeu|verybadbot) 1; ~MaliciousBot 1; ~*(whatever|you|want) 2; } server { if ($bot = 1) { return 403; } if ($bot = 2) { retur
How to force or redirect to SSL in nginx?
I have a signup page on a subdomain like: https://signup.example.com It should only be accessible via HTTPS but I'm worried people might somehow stumble upon it via HTTP and get a 404. My html/server block in nginx looks like this: html { server { listen 443; server_name signup.example.com; ssl on; ssl_certificate /path/to/my/cert; ssl_certificate_key /path/to/my/key; ssl_session_timeout 30m; loca
nginxのキャッシュが効かなくてハマりかけた
こんばんは、ころすけ(@wg_koro)です。 このブログのサーバーで使っているnginxの設定を見直していました。んー、何か遅いよなぁ。 もしかしてnginxのキャッシュ、使われてないんじゃないか？ キャッシュ未使用だと、ページ受信にかかる時間は551ms。 ※各画像はクリックで拡大できます キャッシュが使われると42ms。大違い。 今回設定を見直すまで、ずっと上の「キャッシュ未使用な状態」だったのです。 原因は何だろう とりあえず、ヘッダーにキャッシュステータスを出力させてみる。configファイルのserverブロック以下に下記の一行を追加。 add_header X-Cache $upstream_cache_status; これでレスポンスヘッダにキャッシュ状態が表示されるようになります。 キャッシュが使われるとHIT、使われていない場合はMISSと出力されます。 これであちこち
Subsonic+Nginxのアクセスログをfluentdを利用してMongoDBに入れてみた - Glide Note
Fluentd Casual Talksに参加し、fluentdの使いどころが理解できて、 意識が高いうちに早速fluentdの導入をしSubsonic+nginxのアクセスログをMongoDBに入れてみたのでメモ。 導入環境はwebサーバCentOS 6、ログ収集サーバがCentOS 5で、fluentdのバージョンは td-agent-1.1.5.1-0.x86_64になります。いずれもさくらVPSで稼働させています。 nginxの導入は以前書いた下記のエントリを参考にして下さい。 さくらVPS 2G+Subsonic+Nginxで自分用ストリーミングサーバを構築 - Glide Note - グライドノート 今回行った作業の流れ fluentdを初めて触るので、今回は下記のように順を追って検証と導入を行いました。 fluentdの導入 サーバ1台でwebサーバとログ収集サーバを動かし
NginxでCloudFrontにリダイレクトしてカスタムオリジンで負荷分散する | DevelopersIO
既に運用中のWordPressなどのWebサイトを負荷分散/軽減させたい 既に運用中のWordPressなどのWebサイトに一切手を加えずに負荷分散や軽減をしたいと思いませんでしょうか。そんなとき、Nginxなどのリバースプロキシを入れてコンテンツの圧縮やキャッシュ設定をすることは前回ご紹介しました。今回は、さらに踏み込んで超大規模なアクセスがあったときにも負荷を分散＆軽減できるようにCloudFrontというコンテンツ配信ネットワークサービスを用います。 CloudFront CloudFrontは、AWSが提供しているコンテンツ配信サービスです。主に、S3のオリジンバケットをエッジサーバに配備して負荷分散を行います。まずは配信したいファイルをS3においてからCloudFrontに登録手続きをする必要があったのですが、カスタムオリジンといって既に動いているWebサイトそのものを指定できる
nginxの優雅な再起動 « NAVER Engineers' Blog
こんにちは開発チームの崔珉秀と申します。 今回はnginxというウェブサーバーについて話をさせて頂きます。 nginxは最近数年の間けっこう人気が高くなっています。特によく使われているApacheやLighttpdなどのウェブサーバーと性能の面で比較することがよくありまして、優れた性能で単純なstaticファイルを転送するウェブサーバーからCGIサーバー、reverse proxyサーバーなどの様々なウェブリクエスト処理に関わる分野で導入されています。 今日はnginxの性能の比較よりもサーバーの開発者(nginx module)もしくはサーバーの運営者としてのnginxにある仕組の中で一つを紹介したいと存じます。 サーバーの開発や運営をする場合ロジックや設定などの変更により配布の後、サーバーを再起動することがあります。 その再起動の時にウェブサービスとしてリクエストの処理を続けなが
WebDav Depth Header と Net::HTTP#delete - @kyanny's blog
WebDav の規格で Depth というヘッダがあり、 DELETE メソッドの挙動をコントロールできる。 0, 1, Infinity のいずれかの値をとり、 0 ならば対象のリソース自身を、 1 ならば対象のリソースとそれの直下のリソースを、 Infinity ならば対象のリソース以下のパスの全てのリソースを、それぞれ削除する。 http://www.ietf.org/rfc/rfc2518.txt http://msdn.microsoft.com/en-us/library/aa142852(v=exchg.65).aspx MSDN のドキュメントには noroot というのがあるけどこれは独自実装とかなんだろうか・・・ nginx で特定のパス以下のみ WebDav を有効にして DELETE リクエストを受け付けていたら、リソースの削除ができずエラーログに "XXXX (T
リクエストを落とさずにnginxをアップグレードする方法とその検証
はじめに nginxは頻繁に保守されていてどんどんバージョンが上がっていく一方で、UbuntuやWindows以外ではソースコードからビルドする方法が一般的だと思います。 nginxのバージョンアップ頻度 2011/05/10 1.0.2 2011/05/03 1.0.1 2011/04/12 1.0.0 2011/04/04 0.9.7 2011/03/21 0.9.6 nginx CHANGESより LinuxやBSDの多くのディストリビューションではNginxがパッケージリポジトリに含まれており、通常のソフトウェアインストール手法でインストールする事ができます。(Debianにおけるapt-getや、Gentooにおけるemerge、FreeBSDにおけるports、Fedora の yum、Vine Linux の apt-get など） たまにこれらのパッケージは古いものであった
nginxで特定ホスト以外からのアクセスをメンテナンス画面にする方法 (2) - （ひ）メモ
d:id:sfujiwara:20100812:1281587030 の revise。 Nginxのifは条件節に&&(and)が使えない、ifのネストもできないので、複数の条件で判別したい場合は変数を使うといいよって感じです。 server { ... #error_page 500 502 503 504 /static/50x.html; ### maintenance error_page 500 502 504 /static/50x.html; set $go_maintenance "true"; if ($uri ~ "^/error/") { set $go_maintenance "false"; } if ($remote_addr ~ "^192\.0\.2\.") { set $go_maintenance "false"; } if ($remote_addr
はてなグループの終了日を2020年1月31日(金)に決定しました - はてなの告知
はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28
WordPressを100倍速くする！ MySQLの調整やnginx proxy cache | KRAY Inc
[追記１] 最後で説明しているproxy cacheの設定を修正しました。 [追記２] nginx proxy cacheでキャッシュしない場合の処理を変更しました。 [追記３] スマートフォンや携帯で閲覧した時にキャッシュしない設定を追加しました。 はじめに 大げさな題名ですが、今回はWordPress単体を速くするのではなく、データベースやWebサーバなどの調整、またnginxのproxy cache機能を使って速くする話になります。 サイトの構成によっては、proxy cacheは使えないかもしれませんが、使わなくても5倍程度速くすることはできましたので、参考にしていただければと思います。 今回行うチューニング一覧 DBを最適化するプラグインを導入する APCを導入してPHPを速くする MySQLを速くする 重いWordPressプラグインを外す nginx+FastCGIにする W
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Redirecting to SSL using Nginx
nginxのif – Irako::Blog
Nginx location+proxy_pass?