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

現場で泣かないためのCASBインライン運用：502/504エラーを解き明かす「境界」の真実

ネットワークエンジニアとして現場を歩いていると、避けて通れないのが「見えない壁」との戦いです。特に最近のゼロトラスト移行期において、SASEやCASBを導入した途端、「SaaSが急に繋がらなくなった」という悲鳴が上がることがあります。

中でも、CASBがインラインモード（プロキシ型）で稼働している際に発生する 502 Bad Gateway と 504 Gateway Timeout は、まさに現場のエンジニアを震え上がらせる「悪魔の数字」です。なぜこのエラーが起きるのか、どうやって追跡すべきか。今日はその核心に迫りましょう。

—

502と504の「境界」での立ち位置

まず、RFC 7231における定義を再確認しましょう。これらはどちらもゲートウェイ（この場合はCASB）がサーバとして振る舞い、アップストリーム（SaaS側）と通信した結果として返されるものです。

502 Bad Gateway: アップストリームのサーバから「無効な応答」を受け取った。つまり、プロキシとしてのCASBが、SaaSとのハンドシェイクに失敗したり、不正なHTTPレスポンスを突き返されたりした状態です。
504 Gateway Timeout: アップストリームから「応答が返ってこない」。CASBがリクエストを中継し、待機時間を超えてもSaaSが沈黙している状態です。

これらは、CASBという「検問所」で起きている事故ですが、原因の所在は「検問所そのもの」か、「検問所と目的地（SaaS）の間の道路」か、「目的地」のいずれかにあります。

—

通信シーケンスのリアル：どこで糸が切れたか？

CASBインラインモードの通信フローは、実は非常に複雑です。

1. クライアント → CASB: TLS終端が行われる。ここでCASBは証明書を提示し、通信を解読してコンテンツを検査します。
2. CASB → SaaS: CASBがクライアントの代わりにSaaSへ再接続（オリジン通信）します。
3. SaaS → CASB: レスポンスを返却。
4. CASB → クライアント: 検査済みデータを転送。

502はこの「2」または「3」のステップで発生します。例えば、CASB側がSaaSの最新証明書を検証できず切断した場合、あるいはSaaS側がCASBのIPをボットと誤認して 403 を返したのを、CASBが正しく処理できずに 502 と解釈してしまうケースなどが考えられます。

—

デバッグの現場：curlで「通り道」をテストする

CASBを通さず、あるいはCASBの出口IPから直接SaaSを叩いて、本当にCASBが原因かを確認するのが鉄則です。

# CASBを通さずにSaaSへ直接リクエストを送る（疎通確認）
# -v: 詳細を表示してTLSハンドシェイクの過程を確認する
# -H: 必要に応じてUser-Agentを模倣し、SaaS側の拒否を回避する
curl -v https://api.saas-service.com/v1/resource \
  -H "User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64)" \
  -o /dev/null

もしこれで正常なら、CASB側の「証明書検証設定」や「アップストリームタイムアウト設定」に問題がある可能性が高いです。

—

Pythonによるタイムアウト値のシミュレーション

504が頻発する場合、CASBのタイムアウト設定がSaaSの処理時間より短いことが疑われます。Pythonでその境界をシミュレートする簡単なコードを書いてみます。

import requests

# CASBがSaaSを呼び出す際のタイムアウト値を想定
TIMEOUT_SECONDS = 30 

def test_saas_connection(url):
    try:
        # SaaS側が遅延した場合を想定した呼び出し
        response = requests.get(url, timeout=TIMEOUT_SECONDS)
        response.raise_for_status()
        print("通信成功")
    except requests.exceptions.Timeout:
        # ここで発生するのが実質的な 504 Gateway Timeout
        print("エラー: タイムアウトが発生しました。CASBの閾値を見直すべきです")
    except requests.exceptions.HTTPError as e:
        # ここで 502 Bad Gateway などを捕捉
        print(f"エラー: サーバが不正な応答を返しました: {e}")

test_saas_connection("https://api.saas-service.com/heavy-process")

—

実務上のTips：現場の泥臭い解決策

1. TLSバージョンの不一致: SaaS側が TLS 1.3 を要求しているのに、CASBのプロキシ設定が TLS 1.2 までしか許容していない場合、ハンドシェイク失敗で 502 になります。プロキシの Supported Cipher Suites を確認してください。
2. MTUの不一致: CASBを経由することでパケットサイズがオーバーヘッド分だけ増え、経路上のルーターでパケットがドロップされるケース。MSS Clamping を検討しましょう。
3. SaaS側のIP制限: CASBのグローバルIPがSaaS側に許可されていない場合、SaaS側は接続を拒絶します。CASBベンダーから提供される「出口IPリスト」が最新か、今一度確認を。

最後に：ネットワークは生き物である

ゼロトラストにおいて、CASBはセキュリティの要ですが、同時に「通信のボトルネック」にもなり得ます。エラーが発生したとき、慌てて設定をいじるのではなく、まずは「どこでパケットが止まっているのか」を冷静に切り分けること。

502 か 504 か。このわずかな違いが、あなたのトラブルシューティングの初動を大きく左右します。焦らず、パケットの流れを想像し、一つずつ検証を積み重ねてください。それが、凄腕のエンジニアへの唯一の近道です。