Nginx 1.13 の http_mirror_module を試す - たごもりすメモ
みなさんにも、さまざまな過去の経緯からくる微妙挙動を満載した外部ユーザ向けのHTTPサーバをリプレイスしたりするとき、実際にガツンとやっちまう前にちょっとリクエストを分岐して挙動と性能を確認したい、と思うことがあると思います。考えるだけでつらい気分になってくるやつ。でもやったほうが100倍マシなやつ。 どうしよっかなとちょっと考えたところ、少し前にこんな話があったのを思い出すはずですね*1。 asnokaze.hatenablog.com とはいえヨッシャ使うぞといきなりぶちこむこともできないので、まずいくつか試してみることにする。 準備 前提としては以下のように、元のアプリケーションと同じにホストにリバースプロキシが立っており、そこのnginxで http_mirror_module を使う、という想定*2。ミラー先はどこか適当なアプリケーションサーバ(あるいはロードバランサ)で、元アプ
remote_addrとかx-forwarded-forとかx-real-ipとか - Carpe Diem
背景 ECSでNginxのコンテナをプロキシとして立てたところ、APIサーバのアクセスログのクライアントIPがNginxのコンテナIPになっていたのでその修正をしたのがきっかけです。 環境 Nginx 1.10.2 Docker1.12.1 構成 Client -> ELB -> Nginx -> API という構成とします。 ネットでよく見る情報 set_real_ip_from 172.31.0.0/16; real_ip_header X-Forwarded-For; を追加する、とか proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; を追加する、とかどれがどれだか分かりにくいので１つ１つ説明していきます。 用語説明 remote_
nginxで特定の条件(ソースIPなど)の場合のみreverse proxyとして動作させる設定 - うまいぼうぶろぐ
こんなトリッキーなことしないほうが良い気もするけど。 ソースIPの指定はif $remote_addr で正規表現で書いてもいいけど、複数あると煩雑になるのでgeo使ったほうが楽ですね。 気をつけないといけないのはifのの中などでproxy_passを指定する場合は URLの指定ができない(末尾に"/"つけてはいけない)ので設定を間違えるとエラーになること。 # nginx.conf http { # 略 geo $hoge { default 0; 192.0.1.1 1; 192.0.2.0/24 1; } include vhosts.conf; } # vhosts.conf server { server_name example.com; root /var/www/html; # 略 location /hoge/ { proxy_set_header X-Forwarded
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でリクエスト/レスポンスヘッダーをログ出力
nginx でクライアントの "Accept-Encoding" をログ出力する必要があったので調べた。 ログ出力の基本 ngx_http_log_module モジュールでログ出力する。 nginx.conf の log_format で指定。 Ubuntu では nginx.conf は /etc/nginx/nginx.conf にある。 書式 リクエスト/レスポンスヘッダーともに log_format に $prefix_{field_name} で指定する。 prefix はリクエスト/レスポンスで異なる field_name は正規化しなければいけない。 大文字は小文字にする ハイフンはアンダースコアにする リクエストヘッダーのログ出力 prefix は http Accept-Encoding の場合 $http_accept_encoding となる。 ドキュメントのどこか
最近の Rack サーバ事情について - おもしろwebサービス開発日記
先月、heroku の推しサーバが unicorn から puma に変わったという発表がありました。unicorn だとスロークライアントの影響を受けやすいというのが理由なようです。 もう少し詳しく調べてみましょう。 そもそもスロークライアントってなに その名の通り遅い回線のクライアントです。3G環境のモバイル端末などが該当します。 「unicorn だとスロークライアントの影響を受けやすい」とは unicorn はプロセスモデルのサーバであり、blocking I/O モデルを採用しています。つまり、クライアントとの通信中プロセスが専有されるということです。 例えば unicorn がワーカプロセスを3つ立ち上げていて、そこへ通信完了に10分かかるようなスロークライアントが3つ接続されたら…、続くクライアントはスロークライアントの通信が完了するまで実行を待たなければならなくなります。プ
オブログ - Filed under 'nginxから始めるWebサーバー構築入門'
こんにちは、hsbtです。 今回は nginx を web サーバーとしてではなく、リバースプロキシとして動作させる方法について紹介します。 リバースプロキシとは、Webサーバーより手前に設置し、以下のような機能を提供することを目的としています。 セキュリティの強化 複数のWebサーバーへのアクセスの振り分け Webサーバーの静的コンテンツのキャッシュ 具体例として Rails アプリケーションをWebサーバーで動かしている場合を想定して、nginx をアクセス振り分けを行うリバースプロキシとして用いてみましょう。 nginx でアクセスの振り分けを行う nginx でアクセスの振り分けを行う場合は HttpProxyModule を用います。例えば、Railsアプリケーションが localhost の 3000 ポートで動作している場合に一度 nginx がアクセスを受ける場合は以下のよ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
NginxとLuaを用いた動的なリバースプロキシでデプロイを 100 倍速くした