こんにちは！ネットワークの裏側や、目に見えないパケットの旅路を覗くのが大好きなセキュリティスペシャリストです。
企業ネットワークの世界は今、大きな転換期を迎えています。かつては「会社のオフィスの中（内側）は安全、外のインターネットは危険」という、まるで高い城壁と頑丈な門で守られた中世のお城のような「境界型防御」が主流でした。しかし、リモートワークが当たり前になり、クラウドサービスをフル活用する現代において、そのお城の壁はもう役に立たなくなってきています。
そこで登場するのが、誰も無条件に信用しない「ゼロトラスト」という考え方であり、その中でも主役級の存在であるZTNA（ゼロトラストネットワークアクセス）です。
今回は、そんなZTNAの現場でエンジニアの頭を悩ませる、あの憎きエラーコード「HTTPステータスコード 504（Gateway Timeout）」に焦点を当てていきたいと思います。
「なんだか難しそう……」と思った方も安心してください！ 身近な例えを交えながら、一歩ずつ優しく紐解いていきましょうね。
—
1. そもそもZTNAってなに？ 郵便配達に例えてみよう
ZTNAの仕組みを理解するために、まずは身近な「郵便配達」に例えて考えてみましょう。
従来のVPN（境界型防御）は、いわば「会社専用の合鍵」を社員全員に配り、社内ネットワークという巨大なワンルームマンションの中に自由に出入りさせるようなものでした。これだと、もし合鍵が盗まれたらお部屋の中はやりたい放題になってしまいますよね。
一方、ZTNAはまったく違います。社員（ユーザー）が社内システム（バックエンドリソース）にアクセスしたい時、直接お部屋に入ることはできません。必ず「ZTNAゲートウェイ」という厳重な受付ロビーを経由します。
1. 身元確認（認証）：「あなたは本当に我が社の社員ですか？」とパスポートや社員証を確認します。
2. 荷物の検査（認可・ポリシー確認）：「その荷物をその宛先に送ってもいいルールになっていますか？」と厳しくチェックします。
3. 取り次ぎ（プロキシ動作）：受付の人が、あなたの代わりに社内の奥深くにあるシステムへ荷物を届けに行き、返事を受け取ってあなたに渡します。
この「受付ロビー」がZTNAゲートウェイです。とても安全でスマートな仕組みですよね。
—
2. 犯人は誰だ？「504 Gateway Timeout」が起きる瞬間
さて、この安全な受付ロビー（ZTNAゲートウェイ）を挟んだ通信で、たまにこんなエラー画面に直面することがあります。
> HTTP 504 Gateway Timeout
> ゲートウェイがタイムアウトしました。バックエンドからの応答がありません。
「あれ？ ログインできたのに、なぜか画面が真っ白になってこのエラーが出る……」
これはい一体、裏側で何が起きているのでしょうか？
これも郵便配達で例えてみましょう。
あなたが受付ロビーの窓口（ZTNAゲートウェイ）に行き、「奥の倉庫にある古い台帳を持ってきてください！」と頼みました。受付の人は「かしこまりました！」と倉庫へ向かいました。
しかし、その倉庫の奥にある台帳はホコリまみれで、探すのにものすごく時間がかかっています。あるいは、倉庫への通路が工事中で通れなくなっています。
受付の人は、あなたからの依頼をずっと待っていますが、あまりにも倉庫からの返事がないため、痺れを切らしてこう言いました。
「すみません、倉庫からの返事が一向に来ないので、これ以上待てません！時間切れ（タイムアウト）です！」
これが、504 Gateway Timeout の正体です。
ZTNAの世界に置き換えると、「ユーザーからのリクエストを受け取ったZTNAゲートウェイが、社内のバックエンドサーバー（Webアプリやデータベースなど）に中継したものの、サーバー側が制限時間内に返事を返してくれなかった状態」を指します。
—
3. なぜタイムアウトしてしまうのか？ 主な3つの原因
一歩ずつ、原因を分解して見ていきましょう。現場でよくある原因は大きく分けて3つあります。
原因①：バックエンドの処理が単純に重い・遅い
社内のWebアプリケーションやデータベースが、大量のデータ集計や重い処理をしていて、返事を返すのに時間がかかっているケースです。ZTNAゲートウェイ側は「まだかな、まだかな」と健気に待っていますが、あらかじめ決められた制限時間（タイムアウト値）を超えてしまうと、容赦なく「504」を返します。
原因②：ルーティングやネットワークの迷子（経路不良）
ZTNAゲートウェイからバックエンドリソースへ向かう途中のネットワーク（ファイアウォールや内部ルーターなど）でパケットが迷子になっていたり、セキュリティ機器がパケットをじっくり検査しすぎて遅延が発生しているケースです。
原因③：エージェントレス接続特有のセッション管理の不整合
端末に専用アプリ（エージェント）を入れず、ブラウザだけで接続する「エージェントレス方式（リバースプロキシ型）」の場合、ブラウザとゲートウェイ、そしてゲートウェイとバックエンドの間でセッションの維持に失敗し、通信が途切れてしまうことがあります。
—
4. 現場で使える！トラブルシューティングと対策アプローチ
「504エラーが出たぞ！どうしよう！」とパニックになる必要はありません。プロのネットワークエンジニアは、次のようなステップで冷静に原因を切り分けます。
ステップ1：直接通信できるか試してみる（バイパス検証）
まずは、原因が「ZTNAゲートウェイにあるのか」それとも「バックエンドサーバー自体にあるのか」を切り分けます。可能であれば、ZTNAをバイパスして（あるいは社内LANから直接）バックエンドにアクセスし、同じ処理が正常に終わるか確認します。もし直接でも遅ければ、アプリやサーバー側のチューニングが必要です。
ステップ2：タイムアウト値を見直す（設定変更）
ZTNAゲートウェイの待ち時間が短すぎるのが原因である場合、設定ファイルや管理画面でタイムアウトの閾値を延ばすことで解決することがあります。
例えば、Nginxをベースにしたリバースプロキシ型のZTNAコンポーネントであれば、設定ファイル（nginx.conf など）で次のようなタイムアウト設定を行います。
server {
listen 443 ssl;
server_name ztna-gateway.example.com;
location / {
proxy_pass http://backend-app-server:8080;
# バックエンドからの応答を待つ最大時間を「60秒」から「120秒」に延長する
proxy_read_timeout 120s;
# バックエンドへリクエストを送信する際のタイムアウト
proxy_send_timeout 120s;
# バックエンドとの接続確立を待つタイムアウト
proxy_connect_timeout 60s;
}
}このように、重い処理を扱うアプリケーションサーバーの前段にいるゲートウェイのタイマーを調整してあげることで、エラーを防ぐことができます。
*(※ただし、タイムアウトを延ばすことは「根本的なアプリの重さ」を隠すことにもなりかねないので、長期的にはバックエンドのコード最適化やDBのインデックス見直しもセットで行いましょう！)*
ステップ3：ルーティングとファイアウォールのログを確認する
ZTNAゲートウェイからバックエンドリソースへ向かうパケットが、途中のファイアウォールでブロックされていないか、あるいはルーティングループ（行ったり来たりしてしまう現象）が起きていないかを、ゲートウェイのシステムログやパケットキャプチャで確認します。
—
5. まとめ：安全でスムーズな「受付」を目指して
今回は、ZTNAにおけるHTTPステータスコード 504（Gateway Timeout）の仕組みと原因、そして具体的な対策についてお話ししました。
- ZTNAゲートウェイは、ユーザーと社内システムを安全につなぐ「頼れる受付ロビー」である。
- 504エラーは、受付がバックエンド（倉庫）からの返事を待ちきれずに諦めてしまったタイムアウトのエラーである。
- 原因はバックエンドの処理遅延や、ネットワークの経路不良、タイムアウト値の短さが主である。
ゼロトラストの導入は、セキュリティを強固にする一方で、こうした「ゲートウェイを挟むことによるネットワークの複雑化」を生むことがあります。仕組みを正しく理解し、パケットがどこで足止めを食っているのかを一つずつ紐解いていけば、必ず解決の糸口は見つかります。
「一歩ずつ理解していけば大丈夫！」
日々のインフラ運用やトラブルシューティングも、こうした例えと基本の積み重ねで乗り越えていきましょうね。それでは、また次回の技術解説でお会いしましょう！
コメント