Nginxで、リクエストを複製するmirrorモジュールが標準搭載された - ASnoKaze blog
[20170809追記] nginx-1.13.4に ngx_http_mirror_module は含まれました Nginxで、リクエストを複製するmirrorモジュールがコミットされ、何もせずとも使用できるようになりそうです(現状最新コミットをビルドする必要あり)。 例えば本番環境のproxyからリクエストを複製して開発環境に流すような事も出来ます。もちろん複製処理は本来のリクエスト処理をブロックしません。 例えば以下のように、mirrorに来たリクエストを複製してバックエンドサーバに投げるようにしてみます conf server { listen 80 ; server_name localhost; mirror_request_body on; log_subrequest on; location /mirror { mirror /proxy; #/proxy宛にリクエストを
NGINX Docs | NGINX Load Balancing – TCP and UDP Load Balancer
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 rewriteのlastとbreakの違い
nginx でリライトルールを書くには return または rewrite を使う。 rewrite を使った時の フラグ last と break の違いがわかりにくかったので、簡単にメモ。 return を使ったリライト syntax return code [ text ] (ex. return 403 や return 404 "not found") return code URL (ex. return 301 http://www.example.org$request_uri; ) return URL (ex. return http://www.example.org$request_uri; )code は 302 rewrite を使ったリライト Apache の mod_rewrite に近い。 syntax rewrite regex replacement
nginxでもapacheでも使えるDoS的アクセスを検知して任意の制御をするWebサーバ拡張をmrubyで作った - 人間とウェブの未来
github.com 会社の運用メンバーと色々議論していた中で、「カジュアルにWebサーバへのDoSみたいなアクセスが来た時に検知して制御したいよねー」という話が上がったので、http-dos-detectorというnginxでもapacheでも使えるWebサーバ拡張をmrubyで書きました。 もちろんmrubyなので、mod_mrubyとngx_mrubyを使っています。ので、Rubyコードはそのまま同じコードをどちらのミドルウェアでも使えます。mod_mrubyとngx_mrubyを使えば、ちょっとしたWebサーバの拡張は両方で同じ実装に落とし込めるので便利ですね。 使い方 例の如く、GitHubのREADME通りにインストールして下さい。Rubyのコードはmod_mrubyでもngx_mrubyでも有効なので、そのコードを読み込む設定をそれぞれ以下のように記述するだけでよいです。 a
nginxのパラメータチューニングとh2o - Qiita
(追記:タイトルが少々煽り気味な気がしたので微妙に変更しました。) h2oとnginxの性能比較 nginxよりも速いとされるh2oですが、実際に自分でもローカルでベンチマークを取ってみました。環境は以下の通りです。 EC2のc4.8xlargeインスタンス gcc (GCC) 4.8.2 20140120 (Red Hat 4.8.2-16) Linux ip-172-31-13-40 3.14.35-28.38.amzn1.x86_64 #1 SMP Wed Mar 11 22:50:37 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux nginx-1.8.0 h2o-1.2.1-alpha1 wrk(ベンチマーク) ベンチマークコマンド 実行するベンチマークコマンドは以下になります。なお、オプションはできるだけRequest/secが大きくなるように調
Blacklist Referer Spam Bots with NGINX
Some Background Recently, we submitted fadeit.dk to AWWWARDS - the awards for design, creativity and innovation on the Internet. It gave us a nice little boost of website visitors. However, not all of that attention was positive… Referer Spam Bots While the majority of our traffic came from genuine sources, we started noticing a pattern in our referral traffic. What’s up with social-buttons.com? W
URL中のPath部分のパーセントエンコード - ある異邦人の技術メモ
URLのPath部分でURLエンコードした文字列を扱いたい！ Apacheの裏でPassenger動かしている環境において、パス部分にパーセントエンコードされた文字列を含む、たとえば以下のようなURLを扱おうとすると、問題に直面する。 http://example.com/foo/http%3A%2F%2Fexample.org%2Fbar/baz 何がおこるかというと、Railsにわたる前にApacheが勝手にパーセントデコードしてしまうため、 Railsのroutes.rbで受ける段階で、たとえば以下のような記述をしてもちゃんと意図した形でマッチがなされないためだ。 match '/foo/:url/baz' => .. この問題の解決のため（解決にはなっていないのだが）、泣く泣くサービスの外部仕様を捻じ曲げて、扱うURLの中で、以下のようにパーセントエンコードを2重でかけるという手段
nginxのproxy_read_timeoutはupstreamにも注意 - noob
proxy_read_timeoutが思ったような挙動ではなかったので実験してみた． 想定していた挙動 こんな設定のnginxに対して upstream server_pool_a { server web001:80 max_fails=3 fail_timeout=30s; server web002:80 max_fails=3 fail_timeout=30s; } proxy_read_timeout 60 無限ループするようなCGIをプロキシさせたら web001にリクエスト ↓ 60秒以内にレスポンスが完了しない ↓ 504 Gateway Time-out 発生 となると思っていた． 実際の挙動 ところが実際には以下のような挙動だった． web001にリクエスト ↓ 60秒以内にレスポンスが完了しない ↓ web002にリクエスト ↓ 60秒以内にレスポンスが完了しない ↓
Understanding the Nginx
Nginx is a high performance web server that is responsible for handling the load of some of the largest sites on the internet. It is especially good at handling many concurrent connections and excels at serving static content.�Nginx is one of the most popular web servers in the world. It can successfully handle high loads with many concurrent client connections, and can easily function as a web se
Nginx導入時、サクッと対応しておくと良いかもしれない - Qiita
HTTPレスポンスヘッダにサーバのバージョンの表示を消す なぜ必要？ 潜在攻撃者への情報提供になることも。 もし使用中バージョンの脆弱性が明らかになった時、恰好の標的になるとか。 対応 nginx.confのhttpディレクティブに server_tokens off; を追加。
調べなきゃ寝れない！と調べたら余計に寝れなくなったソケットの話 - Qiita
なるほど、最近ソケット通信、ソケット通信と言ってるのはUNIXドメインソケットの事か！ UNIXドメインソケットって何がいいの？ Performance Analysis of Various Mechanisms for Inter-process Communicationに素晴らしい検証があった。 It was hypothesized that pipes would have the highest throughtput due to its limited functionality, since it is half-duplex, but this was not true. For almost all of the data sizes transferred, Unix domain sockets performed better than both TCP so
[nginx]S3をバックエンドにngx_small_lightで画像を動的にリサイズ
S3 で公開しているバケットをバックエンドに nginx モジュール ngx_small_light を利用して画像をリサイズする方法をメモ http://d.hatena.ne.jp/akishin999/20130619/ にローカルの画像を対象にした画像変換手順が書かれているので、そこに S3 バックエンドを追記しただけとも言える。 ngx_small_light について github で公開 https://github.com/cubicdaiya/ngx_small_light pixiv の中の人が開発した nginx モジュール Apache 向け mod_small_light の nginx 移植 https://code.google.com/p/smalllight/ 画像変換エンジンは ImageMagick/Imlib2/GD から選択可能 構成 client
![[nginx]S3をバックエンドにngx_small_lightで画像を動的にリサイズ](https://cdn-ak-scissors.b.st-hatena.com/image/square/558d53bd8632c04537f9b0ff297877a64b26b110/height=288;version=1;width=512/https%3A%2F%2Fsiguniang.files.wordpress.com%2F2014%2F01%2Fbenchmark1.png)
Nginxの脆弱性(CVE-2013-4547)へのChefを使った対応 | Engine Yard Blog JP
脆弱性の内容 Nginxにセキュリティ設定を迂回できる脆弱性(CVE-2013-4547)が報告されました。この問題はNginxのバージョン、0.8.41 - 1.5.6が影響を受けると報告には記されています。内容については下記のようなセキュリティ設定を迂回できるというものです。 location /protected/ { deny all; } 迂回の方法はスペースを使ったURL,「/foo /../protected/file」やPHPなどの処理を呼び出す部分にやはりスペースがある事で実行できるとのことです。詳細についてはメーリングリストの投稿を御覧ください。 Engine Yardでの対応 Engine Yardでは該当の問題に対する修正パッチを適用したクックブックを脆弱性の報告から2日後(2013/11/21)にリリース済みです。 Engine Yardのダッシュボード上でアッ
G-WANはなぜ速いのか？をnginxと比べながら検証してみた - blog.nomadscafe.jp
ツチノコブログのWEBサーバベンチマークツール比較の記事で紹介されていた。WebサーバのG-WAN。この記事によると凄く速いようです。 Intel Xeon E5-2640 (6コア/12スレッド 2.50GHz) を2つというサーバで gwan 334944 req/s nginx 111842 req/s と、速いと言われているnginxの3倍の速度を出しています。 このベンチマーク結果がとても気になったので、なぜG-WANが速いのか、自分でも検証してみました。 結論から言うと以下の2つ。 1) G-WANはデフォルトで物理CPUに合わせた数のスレッドを起動する 2) HTMLファイルも一度読み込んでキャッシュする という事です。 今回はAWSのcc2.8xlarge(E5-2670 8コア/16スレッド 2.60GHz *2)を使ってベンチマークを行いました。OSはAmazon L
nginx(1.3.13)でWebSocketをリバースプロキシしてみる - 人と技術のマッシュアップ
nginx(1.3.13)でWebSocketのプロキシを試してみました 2013/2/19にnginxが正式にWebSocketに対応したとアナウンスがあったので、試しに使ってみました。 ダウンロード・インストール ここからnginx-1.3.13をダウンロードしてきて、インストールします。 インストールオプションはあえてデフォルトで $ wget http://nginx.org/download/nginx-1.3.13.tar.gz $ tar xvf nginx-1.3.13.tar.gz $ cd nginx-1.3.13 $ ./configure $ make $ sudo make install 設定ファイルの書き換え 次にnginx.confを書き換えます。構成は リバースプロキシ: 192.168.0.8:80 バックエンドサーバ: 192.168.0.2:3000
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
実践nginx〜メルカリの場合〜
IDEA * IDEA
『httpsだからというだけで安全？調べたら怖くなってきたSSLの話!？ - Qiita』へのコメント
Nginx SSL and Varnish | Edoceo
はてなブログ | 無料ブログを作成しよう
