パッケージのみで CentOS の Nginx を HTTP/2 対応にする - Qiita
CentOS 7.4 から OpenSSL が 1.0.2 にバージョンアップされたため、完全にパッケージのみで Nginx を HTTP/2 に対応させることが可能になりました。 Apache は「パッケージのみで CentOS の Apache を HTTP/2 対応にする」を参照してください。 Nginx は 1.9.5 から HTTP/2 がサポートされました。1 リポジトリ EPEL リポジトリおよび Nginx 公式リポジトリのいずれでも Nginx 1.12.2 がインストールされますが、設定ファイルなどの内容が異なります。 EPEL リポジトリ yum -y install epel-release && yum -y update && yum -y install nginx sed -i'/^# / s/^#//' /etc/nginx/nginx.conf EPEL
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_passの注意点 -- ぺけみさお
nginxをリバースプロキシにする場合に使用するproxy_passディレクティブは、URIが与えられた場合と、そうでない場合で挙動が異なる。 どういうことかというと、以下の1.と2.は別々の結果となる。proxy_passディレクティブの引数に注目して欲しい。 # 1. specified with a URI location /name/ { proxy_pass http://127.0.0.1/; } 1.はproxy_passディレクティブに完全なURIを与えた例である。この場合http://example.com/name/fooへのアクセスは、/nameが削除されたhttp://127.0.0.1/fooへ転送される。 2.はproxy_passディレクティブに完全なURIを与えなかった例である。この場合http://example.com/name/fooへのアクセスは、
nginx+puma+rails の worker,thread,connection pool 数の目安 - Qiita
nginx+puma+rails の worker,thread,connection pool 数の目安Railspuma ※間違ってたら指摘を... 前提 MRI(Matz's Ruby Implementation) の前提, JRubyの場合は考え方が変わる。 nginx の worker 数の目安 CPUコア数を基本とする。ただし... 一方で、例えば僕の用途では、現在画像の処理だったりとか、ngx_mrubyのようにリクエストの過程で一部ブロッキングされるような処理も増えてきているため、コア数以上の値に設定しておいた方が性能を発揮できるような状況も増えてきています。 nginxのworkerプロセス数をCPUコア数の倍数で自動的に設定できるモジュールを書いた - 人間とウェブの未来 上記のようにコア数以上に設定した方が良いケースも時としてあるようです。 nginx の work
nginxで"client intended to send too large body"が発生した時の対策方法 - Qiita
nginx が稼働しているWebページで、フォームからファイルをアップロードしようとしたら、 "1 client intended to send too large body: 1367171 bytes" というエラーが発生しました。 これは、nginx が POST の最大サイズを超えるデータが送られてきた場合に発生するエラーのようです。 http://wiki.nginx.org/HttpCoreModule#client_max_body_size によると、nginx ではデフォルトで1MBまでのデータしか受け付けないようです。 nginx が1MBより大きなデータを受け取れるようにするには、nginx.conf で client_max_body_size ディレクティブを設定します。 client_max_body_size は http, server, location
【nginx】レスポンスタイムアウトの設定メモ｜ばちブロ
[PR]上記の広告は3ヶ月以上新規記事投稿のないブログに表示されています。新しい記事を書く事で広告が消えます。 ちょっとしたメモ代わりに。 割と重要で、なかなか参考になるものがなかったので。 以下3つの設定値について、ちょっと調べてみました。 proxy_connect_timeout proxy_send_timeout proxy_read_timeout 参考書などの説明によると、各設定値はこんな感じの説明をされていました。 ■proxy_connect_timeout バックエンドサーバとの接続タイムアウト時間の指定 バックエンドサーバに接続要求を送り、n秒間接続できない場合発生 すでにバックエンドと接続されている場合、このタイムアウトは発生しない ■proxy_send_timeout バックエンドサーバへのデータ送出のタイムアウトの秒数を指定 このタイムアウトは、応答全体の遅れ
nginxのタイムアウト時間を伸ばす - 諸行無常
defaultは60秒 sudo vi /etc/nginx/nginx.conf httpブロックのタイムアウト時間を変更する（秒） http{ ... proxy_read_timeout 300; proxy_connect_timeout 300; proxy_send_timeout 300; ... } 特定のサーバだけ、時間変えたい時 server{ ... proxy_read_timeout 300; proxy_connect_timeout 300; proxy_send_timeout 300; ... } 再起動 sudo systemctl restart nginx 確認 systemctl status nginx
nginx + unicorn + sinatra で接続元IPを取得する - simotin13's message
nginx + unicorn + sinatraで構築したWebサイト(nginx)で不正アクセスをアプリケーション層ではじく処理を書きたくなって、少しはまったので書いておきたいと思います。 ■目次 $env["REMOTE_ADDR"] $env["REMOTE_ADDR"]が 127.0.0.1 になる proxy_set_headerを設定する 感想 専守防衛 $env["REMOTE_ADDR"] Webアプリで不正アクセスを防ぐ場合、接続元のIPアドレスを見て、怪しいやつ(例.ログインフォームで何回もログインに失敗しているやつ)を出禁にしてしまうという手法が手っ取りばやいだろう。ということで、サイトへのログイン処理にそのような処理を入れてみました。 ※銀行のオンラインバンキングなどでよくあるパスワード間違えるとログインできなくなるというやつですね。 sinatraでは接続元のI
プロキシ経由時のリモートアドレスについて！
mk-mode.com Linux, Debian, IT, Server, PG, Ruby, Rails, Python, C++, Fortran, PC, MariaDB, math, GIS, etc... 少し前から当方の Ruby on Rails 製のホームページを Apache + Passenger から Nginx + Unicorn に変更して運用しています。 しかし当初、プロキシの関係で、アクセス解析処理の部分でリモートアドレスが正常に取得できなくなっていました。 以下、対応記録です。 1. 現象 Nginx でバックエンド（プロキシサーバ）へ HTTP ヘッダ情報を送信しているにも関わらず、Rails 側で環境変数 REMOTE_ADDR を取得すると全て “127.0.0.1” になってしまう。 Nginx のログでは正常にリモートIPアドレスが取得できるのを
多段nginxでもX-Forwarded-ForできちんとバックエンドにクライアントIPアドレスを伝える
# 多段nginxでもX-Forwarded-ForできちんとバックエンドにクライアントIPアドレスを伝える 2019/08/17 nginx 主にバックエンドにRailsを利用する環境向け。LBやリバースプロキシの背後にあるバックエンドサーバにクライアントIPアドレスを伝える方法の一つとして、`X-Forwarded-For`というHTTPリクエストヘッダがあります。nginxをLBやリバースプロキシとして構築し、それらを複数経由させてバックエンドのAPサーバにアクセスさせる際でも、 このリクエストヘッダを利用してきちんとバックエンドにクライアントIPアドレスを伝える方法をメモします。 # X-Forwarded-For(以下XFF)とは LBによるL4以上でのD-NATや、リバースプロキシによる代理アクセスなど、IPヘッダのソースIPアドレスがクライアントのIPアドレスからその中継機器
nginxでX-Forwarded-Forの値に$proxy_add_x_forwarded_forを安易に使わない方が良い
nginxでX-Forwarded-Forの値に$proxy_add_x_forwarded_forを安易に使わない方が良い 公式ドキュメントの $proxy_add_x_forwarded_for の説明問題1:nginxがXFFを生成するフロントエンドの場合、XFFの改ざんが可能になる問題1:どうすればいいか問題2::real_ip_headerなどで$remote_addrが変更されている場合、正しく上流プロキシのIPアドレスをXFFに追加できない問題2:期待されるXFFの値とこの設定で実際に設定されるXFFの値問題2: どうすればいいか # nginxでX-Forwarded-Forの値に$proxy_add_x_forwarded_forを安易に使わない方が良い 2019/08/17 nginx nginxでX-Forwarded-Forヘッダを付与するのに$proxy_add_
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_
こんばんは、X-Forwarded-For警察です - エムスリーテックブログ
エムスリーエンジニアリンググループ製薬企業向けプラットフォームチームの三浦 (@yuba)です。普段はサービス開発やバッチ処理開発をメインにやっておりますが、チームSREに参加してからはこれに加えて担当サービスのインフラ管理、そしてクラウド移行に携わっています。 今回はそのクラウド移行の話そのものではないのですが、それと必ず絡んでくるインフラ設定に関してです。 アクセス元IPアドレスを知りたい Webアプリケーションがアクセス元IPアドレスを知りたいシーンというのは、大まかに二つかと思います。ログ記録用と、アクセス制限ですね。どちらもアプリケーションそのものではなく手前のWebサーバの責務のようにも思えますが、そうとも言い切れません。動作ログ、特に異常リクエストをはじいた記録なんかにセットでIPアドレスを付けたいとなるとアプリケーション要件ですし、アクセス制限についてもマルチテナントサービ
Amazon Linux 2にExtrasレポジトリからNginxをインストールする | DevelopersIO
Amazon Web Services (AWS) が提供しているAmazon Linuxに新世代のAmazon Linux 2(以下AL2)がリリースされました。 AL2 には Extras と呼ばれるレポジトリが存在し、Python、Golang、MariaDB、Ansible などの特定のパッケージをより新しいバージョンで利用することが出来ます。 今回は Extras レポジトリ経由で Nginx をインストールする方法を紹介します。 3行まとめ Amazon Linux 2に Nginx をインストール Extras レポジトリで提供される Nginx を利用 サービス管理は systemd を利用 Extras Library から Nginx をインストール AL2 では標準で Nginx の YUM 向けパッケージが提供されていません。 $ yum search nginx
Nginx のリバースプロキシ設定のメモ - Qiita
Nginx でリバースプロキシをする場合に、どうやってセキュアなリクエストであることをアプリケーションに伝えるか？のメモ。 Nginx - Rails の場合 NginxでリバースプロキシするときにもSSLはNginxで処理させる場合が多く、プロキシされるアプリケーションサーバにはSSLが解かれた状態でリクエストが届く。 そのため次のヘッダをNginxでつけるように設定する必要がある。 server { listen 80; server_name hoge.com; location / { proxy_set_header X-Real-IP $remote_addr; index index.html index.htm; proxy_set_header X-Forwarded-Proto $scheme; proxy_set_header X-Forwarded-For $pro
【Play Framework】 ELB 経由のアクセス元IPアドレスを取得する | DevelopersIO
Play Framework に対するアクセスから ELB や nginx（リバースプロキシ）を経由した アクセス元IPアドレス を取得するには、少し工夫が必要です。 本記事におけるバージョン情報は下記の通りです。 Play Framework 2.4 Scala 2.11.4 nginx 1.6.2 下準備: IP確認するアプリケーションを用意する アクセス元IPアドレスをどのように取得すればいいかを知るために、まず、アクセス元IPを確認するアプリケーションを作成しましょう。 ipcheck.scala.html @(remoteAddr: String, xForwardedFor: String, xRealIp: String) @main("IP Check") { <dl> <dt>Your remoteAddress</dt> <dd>@remoteAddr</dd> <dt
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
【Nginx】「nginx: [emerg] SSL_CTX_set_cipher_list(“PROFILE=SYSTEM”) failed」と出て起動しない | 株式会社ヴァンデミックシステム
Wrong IP-Address with nginx + Unicorn + rails
nginxによる実践的Webシステム / Practical nginx web system
ノンブロッキングI/Oと非同期I/Oの違いを理解する
