NGINX は、高トラフィック負荷を処理し、静的コンテンツを効率的に提供する能力で有名な、高性能 Web サーバーおよびリバース プロキシ サーバーです。その強力な機能の 1 つは URL をリダイレクトする機能です。これは、Web トラフィックの管理、SEO の改善、スムーズなユーザー エクスペリエンスの確保に不可欠な機能です。NGINX の URL リダイレクトは、HTTP から HTTPS へのリダイレクト、URL エイリアスの作成、サイト移行の管理など、さまざまな目的で使用できます。
次のガイドでは、Linux または Unix 系システム上のコマンドライン ターミナルを使用して NGINX で URL をリダイレクトする方法を説明します。NGINX の堅牢で柔軟なリダイレクト機能を構成することで、特定の要件を満たすように Web トラフィックを効率的に管理および制御できます。
NGINXでリダイレクトURLを返す
NGINX は、URL リダイレクトを設定するための 2 つの主要なディレクティブを提供します。 return そして rewriteこれらのディレクティブは、Web トラフィックをある URL から別の URL に転送するために重要です。
NGINX での 301 リダイレクト
301リダイレクトは恒久的なリダイレクトに不可欠です。これは、ウェブサイトまたはウェブページが新しいURLに恒久的に移動されたときによく使用されます。NGINXで301リダイレクトを設定するには、 return ディレクティブをサーバー ブロック内に挿入し、301 ステータス コードを指定します。これにより、ユーザーと検索エンジンの両方が新しい URL にリダイレクトされるようになります。
301 リダイレクトの例
トラフィックをリダイレクトする必要があるとします oldsite.com に newsite.comNGINX の設定は次のようになります。
server {
listen 80;
server_name oldsite.com;
location / {
return 301 $scheme://www.newsite.com$request_uri;
}
}
この設定により、 oldsite.com に www.newsite.com元のリクエスト URI を維持します。このシンプルかつ強力な方法により、ユーザーと検索エンジンが新しい Web サイトの場所を見つけられるようになります。
NGINX の 302 リダイレクト
永続的なリダイレクトとは対照的に、302 リダイレクトは一時的なリダイレクトのシナリオに使用されます。たとえば、Web サイトのメンテナンス中やページが一時的に移動されたときに、ユーザーを一時的にリダイレクトする場合があります。
302 リダイレクトの例
例えば、次のURLからのトラフィックをリダイレクトしたいとします。 temp.com に another-site.com 一時的に。NGINX の設定は次のようになります。
server {
listen 80;
server_name temp.com;
location / {
return 302 $scheme://www.another-site.com$request_uri;
}
}この構成では、 temp.com 一時的にルートが変更されます www.another-site.com302 ステータス コードの使用は、このリダイレクトが一時的であることを示しており、これは短期的な変更中に SEO の整合性を維持するために重要です。
NGINX のリダイレクト URL を書き換える
の rewrite NGINXのディレクティブは、複雑なURLリダイレクトシナリオを処理するための強力なツールです。単純な return 指令、 rewrite 正規表現と幅広い変数を活用します。この柔軟性により、特に単純なリダイレクトでは不十分なシナリオで、URL のリダイレクト方法を正確に制御できます。
ファイル拡張子に基づくリダイレクト
特定のファイルタイプのリダイレクト
一般的な要件は、特定のファイルタイプをリダイレクトすることです。たとえば、すべての .jpg 新しいディレクトリへの画像リクエスト:
server {
listen 80;
server_name www.example.com;
location ~* \.jpg$ {
rewrite ^/images/(.*)\.jpg$ /new-images/$1.jpg permanent;
}
}この構成では、 .jpg ファイルの /images/ ディレクトリがリダイレクトされる /new-images/正規表現 \.(jpg)$ で終わるURLのみが .jpg 影響を受けます。
URI に基づく動的リダイレクト
URI 操作によるリダイレクト
もう 1 つの一般的なシナリオは、URI コンポーネントに基づいて URL を動的にリダイレクトすることです。製品カテゴリに基づいてユーザーをリダイレクトすることを検討してください。
server {
listen 80;
server_name www.example.com;
location ~* ^/category/(.*)$ {
rewrite ^/category/(.*)$ /new-category/$1 permanent;
}
}この設定では、以下のURLをキャプチャします。 /category/ 対応するURLにリダイレクトします。 /new-category/URI の後半部分は維持されます。
レガシー URL 構造の処理
古い URL を新しいパターンにリダイレクトする
ウェブサイトのURL構造は時間の経過とともに変化することがよくあります。 rewrite ディレクティブはこのような遷移をスムーズに処理できます。
server {
listen 80;
server_name www.example.com;
location ~* ^/old-structure/(.*)$ {
rewrite ^/old-structure/(.*)/info$ /new-structure/$1/details permanent;
}
}
この例では、古いパターン（/old-structure/[identifier]/info) を新しいパターン (/new-structure/[identifier]/details).
地理ベースのリダイレクト
地理的位置によるユーザーのリダイレクト
NGINXは、地理的な場所に基づいてリダイレクトを処理することもできます。 $geoip_country_code 変数：
server {
listen 80;
server_name www.example.com;
if ($geoip_country_code = "US") {
rewrite ^/(.*)$ /us/$1 permanent;
}
}この構成では、米国からの訪問者はウェブサイトの米国固有のセクションにリダイレクトされます。このアプローチでは、NGINX で GeoIP モジュールを有効にする必要があります。
NGINX でのリダイレクト URL の負荷分散
NGINX は、負荷分散とリダイレクト機能を通じてネットワーク トラフィックを効率的に管理することに優れています。NGINX の負荷分散では、着信トラフィックを複数のサーバーに分散します。この戦略により、単一のサーバーが過負荷になるのを防ぎ、システム全体のパフォーマンスと信頼性が向上します。
負荷分散のための NGINX の設定
負荷分散の設定
基本的な負荷分散
負荷分散のために NGINX を構成する方法の例を次に示します。
http {
upstream backend {
server backend1.example.com;
server backend2.example.com;
server backend3.example.com;
}
server {
listen 80;
location / {
proxy_pass http://backend;
}
}
}この構成では、NGINX はリバース プロキシとして機能し、受信リクエストを指定された 3 つのバックエンド サーバー (backend1.example.com、backend2.example.com、backend3.example.com) のいずれかに均等に分散します。この設定は、トラフィック量の多い Web サイトにとって非常に重要です。効率的なリクエスト処理が保証され、応答時間が短縮され、サーバーのダウンタイムが最小限に抑えられるためです。
ヘルスチェックによる高度な負荷分散
信頼性を向上させるために、バックエンド サーバーでヘルス チェックを実行し、正常なサーバーにのみトラフィックを送信するように NGINX を構成できます。
http {
upstream backend {
server backend1.example.com;
server backend2.example.com;
server backend3.example.com;
# Enable health checks
health_check;
}
server {
listen 80;
location / {
proxy_pass http://backend;
}
}
}
この設定により、NGINX はバックエンド サーバーの正常性を定期的にチェックし、ダウンしているサーバーを負荷分散プールから除外します。これにより、トラフィックはリクエストを処理できるサーバーにのみ送信されるようになり、全体的な信頼性が向上します。
負荷分散のベストプラクティス
セッション永続性の実装 (スティッキーセッション)
セッションの永続性を必要とするアプリケーションでは、スティッキー セッションを使用して、ユーザーが常に同じバックエンド サーバーにルーティングされるようにすることができます。
http {
upstream backend {
ip_hash;
server backend1.example.com;
server backend2.example.com;
server backend3.example.com;
}
server {
listen 80;
location / {
proxy_pass http://backend;
}
}
}この構成では、 ip_hash ディレクティブにより、同じクライアント IP アドレスからのリクエストが常に同じバックエンド サーバーにルーティングされ、セッションの一貫性が維持されます。
SSL終了の設定
安全な通信のためには、ロード バランサーで SSL を終了するのがベスト プラクティスです。
http {
upstream backend {
server backend1.example.com;
server backend2.example.com;
server backend3.example.com;
}
server {
listen 443 ssl;
ssl_certificate /etc/nginx/ssl/nginx.crt;
ssl_certificate_key /etc/nginx/ssl/nginx.key;
location / {
proxy_pass http://backend;
}
}
}この設定では、NGINX が SSL 終了を処理し、受信した SSL 要求を復号化して、通常の HTTP 要求としてバックエンド サーバーに転送します。これにより、バックエンド サーバーから SSL 処理の負荷が軽減され、パフォーマンスが向上します。
結論
このガイドでは、URL リダイレクト、負荷分散などに NGINX を使用する実用性について説明しました。基本的な 301 および 302 リダイレクトの設定から、複雑な書き換えルールや効率的な負荷分散構成の実装まで、さまざまな手法を取り上げました。NGINX の強みは柔軟性とパフォーマンスにあり、小規模から大規模まで、あらゆる Web サイトの管理に欠かせないツールとなっています。これらの概念を適用しながら、実験と最適化を続けてください。NGINX は Web 管理の武器となる強力なツールです。サイトをスムーズかつ効率的に運用するために使用してください。
