【入門編】 CASBインラインモードにおけるHTTPステータスコード502(Bad Gateway)と504(Gateway Timeout)の原因 – ゼロトラスト＆エンタープライズセキュリティ実践ガイド

こんにちは！ネットワークやセキュリティの世界へようこそ。インフラエンジニアとして現場を駆け巡っていると、時として「うわ、またエラーが出たぞ……」と冷や汗をかく瞬間に出会いますよね。

特に、会社全体でクラウドサービス（SaaS）を安全に使おうと導入した「CASB（キャスビー）」や「SASE（サース）」の環境下で、ブラウザに突如として現れる不気味な数字――それが 502 Bad Gateway や 504 Gateway Timeout です。

「なんだか難しそうなエラーだな、ネットワークの奥底で複雑なパケットがケンカでもしているのかな？」と身構えてしまうかもしれませんが、大丈夫です。一歩ずつ、身近な例えから紐解いていけば、必ず原因と対策が見えてきますよ。

今回は、この厄介な2つのHTTPステータスコードの正体を、郵便配達のストーリーになぞらえて一緒に優しく解き明かしていきましょう！

—

1. そもそもCASBの「インラインモード」ってなに？

私たちが普段使っているMicrosoft 365やGoogle Workspace、SlackなどのSaaSへアクセスする際、社外の通信を守るために CASB というセキュリティの門番が間に立っていることがあります。

中でも「インラインモード（プロキシモード）」と呼ばれる仕組みは、ユーザーがSaaSへ送るすべての通信（手紙）を、必ず一度CASBという「中継所」を通過させる方式です。
CASBの中継所では、「おや、この手紙にはマルウェア（ウイルス）の怪しい粉がついていないか？」「社外秘のデータが勝手に外へ持ち出されていないか？」という厳しいチェックがリアルタイムで行われています。

この「中継所」がしっかり機能しているからこそ企業秘密が守られるわけですが、時としてこの中継所の前後でトラブルが起き、先ほどの 502 や 504 というエラーが返ってくることになるのです。

—

2. 【502 Bad Gateway】は「中継所とSaaS本社の連絡ミス」

身近な例えでイメージしよう

あなたが「本社（SaaS基盤）」宛ての重要な荷物を送ろうと、街の「中継所（CASBプロキシ）」に立ち寄ったとします。
ところが、中継所のスタッフが本社へ電話をかけたところ、「現在、電話回線の工事中で向こうにつながりません！」あるいは「向こうから意味不明な返事が返ってきて、荷物を渡せません！」となった状態。これが 502 Bad Gateway です。

あなたの手元（ブラウザ）から中継所までは無事に届いているのに、中継所から先の「本当の目的地（SaaS）」との間でうまく連絡が取れなくなっている状態を指します。

主な原因と現場でのチェックポイント

インラインモードのCASB環境において、502 エラーが出る代表的な原因には以下のようなものがあります。

  • SaaS側の一時的な障害やメンテナンス: 本社自体がダウンしている場合。
  • CASBとSaaS間のルーティング・名前解決（DNS）の不具合: 中継所がSaaSの正しい住所を見失っている場合。
  • SSL/TLS復号（インスペクション）の証明書トラブル: 中継所が通信の中身を検査するために「偽の証明書」を差し替えるのですが、その信頼関係が崩れてSaaS側から門前払いされてしまう場合。

—

3. 【504 Gateway Timeout】は「中継所の検査が長すぎてタイムアウト」

身近な例えでイメージしよう

今度は、あなたが中継所に「ものすごく巨大で複雑なデータが詰まったダンボール箱（大容量のファイルアップロードや複雑なデータベース検索）」を持ち込んだとします。
中継所のスタッフはルール通り、一つひとつの荷物を丁寧に、それはもう慎重にスキャンし始めました。

しかし、荷物が大きすぎてスキャンにめちゃくちゃ時間がかかってしまいました。後ろで待っているお客さんもイライラ、「これ以上待たせたらルール違反だ！」とタイマーが「ピピピッ！」と鳴り響き、スタッフが「すみません、時間がかかりすぎて処理しきれませんでした！」とギブアップしてしまった状態。これが 504 Gateway Timeout です。

主な原因と現場でのチェックポイント

CASBのインラインモードでは、通信をすべて覗き見してマルウェアスキャンやDLP（情報漏洩対策）のパターンマッチングを行っています。そのため、以下のような場面でこのタイムアウトが発生しやすくなります。

  • 巨大なファイルのアップロード/ダウンロード: 数GB単位のファイルをやり取りする際、CASBの検査時間がプロキシの「待ち時間（タイムアウト値）」を超えてしまう。
  • 重いクエリやレスポンス: SaaS側からのデータの戻りが遅く、中継所が待ちくたびれてしまった場合。

—

4. 現場で役立つ！タイムアウト値を調整する設定例

もし 504 Gateway Timeout が頻発し、どうしても巨大なファイルのやり取りを許可したい場合は、CASBプロキシやリバースプロキシ（Nginxなど）のタイムアウト設定を見直す必要があります。

例えば、Nginxをプロキシサーバーとして運用している環境であれば、以下のような設定パラメータで「待ち時間」を延ばすことが可能です。

# Nginxにおけるプロキシタイムアウト設定のサンプル
server {
    listen 443 ssl;
    server_name casb-proxy.example.com;

    # バックエンドのSaaSサーバーへ接続を試みる際のタイムアウト（秒）
    # デフォルトより長めの 60秒 に設定
    proxy_connect_timeout 60s;

    # バックエンドからのデータ送信を待つタイムアウト（秒）
    # 重い処理や大容量通信に対応するため 300秒（5分）に延長
    proxy_send_timeout 300s;
    proxy_read_timeout 300s;

    location / {
        proxy_pass https://backend.saas-provider.com;
        
        # クライアントからの巨大なファイルアップロードを許容するサイズ設定
        client_max_body_size 500M;
    }
}

> 💡 ワンポイントアドバイス:
> タイムアウト値をただ闇雲に延ばせば解決するわけではありません。あまりに長い時間待ち続ける設定にすると、今度はネットワーク全体の回線が占有され、他のユーザーの快適な通信まで巻き込んで遅くなってしまう「二次災害」を引き起こすリスクがあります。業務上本当に必要な大容量通信（例: 特定のバックアップデータ転送など）は、CASBの検査対象から「バイパス（除外）」する設計上のアプローチも検討してくださいね。

—

5. まとめ：エラーコードはネットワークからの「道しるべ」

今回は、CASBのインラインモードでよく遭遇する 502 Bad Gateway と 504 Gateway Timeout について、郵便配達の例えを交えながら解説しました。

  • 502 は「中継所から先（SaaS）との連絡がつかない！」
  • 504 は「中継所での検査に時間がかかりすぎてタイムアウトした！」

エラーコードは、決してシステムからの「意地悪」ではなく、「今、この区間でこんなトラブルが起きていますよ」と教えてくれる大切な道しるべです。
次にこれらのエラーに直面したときは、「ユーザーから中継所まではOKだな。じゃあ中継所とSaaSの間、あるいは検査の重さに原因があるはずだ」と、頭の中ですっきりと切り分けてトラブルシューティングに臨んでみてください。

あなたのインフラライフが、少しでも快適でワクワクするものになりますように。それではまた次の技術でお会いしましょう！

スポンサーリンク

コメント

タイトルとURLをコピーしました