Proxy

HTTP とネットワークのトラフィックを Gateway に転送し、ログ記録とフィルタリングができます。Gateway は、アウトバウンドトラフィックと、Cloudflare Tunnel、Generic Routing Encapsulation（GRE）トンネル、または IPsec トンネルで接続されたリソース向けのトラフィックの両方をプロキシできます。ユーザーが Gateway proxy に接続すると、Gateway はその接続を受け付け、オリジンサーバーへ新しい別接続を確立します。

Traffic and DNS モードの Cloudflare One Client 経由で HTTP とネットワークトラフィックをフィルタするには、Gateway proxy が必要です。Cloudflare One Client を導入せずに HTTP トラフィックをプロキシする場合は、デバイスで PAC ファイルを設定できます。

プロキシアルゴリズム

Gateway は Happy Eyeballs アルゴリズム ↗ を使います。IPv4 と IPv6 の接続をずらして試し、先に応答したアドレスファミリーを使います。トラフィックは次の順でプロキシします。

ユーザーのブラウザーが TCP SYN セグメントを Gateway に送り、TCP ハンドシェイクを開始します。
Gateway がオリジンサーバーへ SYN セグメントを送ります。
オリジンサーバーが SYN-ACK セグメントを返すと、Gateway はユーザーと Gateway のあいだ、および Gateway とオリジンサーバーのあいだに、別々の TCP 接続を確立します。
Gateway はユーザーから受け取ったトラフィックを検査してフィルタします。
検査を通過したトラフィックは、Gateway がユーザーとオリジンサーバーのあいだで双方向にプロキシします。

flowchart TD
    %% Accessibility
    accTitle: Gateway プロキシの仕組み
    accDescr: Gateway プロキシが Happy Eyeballs アルゴリズムで TCP 接続を確立し、ユーザートラフィックをプロキシする流れを示すフローチャートです。

    %% Flowchart
    A[ユーザーのデバイスが Gateway へ TCP SYN を送信] --> B[Gateway がオリジンサーバーへ TCP SYN を送信]
    B --> C{{オリジンサーバーが TCP SYN-ACK で応答する？}}
    C -->|はい| E[TCP ハンドシェイク完了]
    C -->|いいえ| D[接続失敗]
    E --> F{{接続は許可される？}}
    F -->|Allow ポリシー| G[Gateway が双方向にトラフィックをプロキシ]
    F -->|Block ポリシー| H[ファイアウォールポリシーにより接続をブロック]

    %% Styling
    style D stroke:#D50000
    style G stroke:#00C853
    style H stroke:#D50000

対応プロトコル

Gateway は TCP、UDP、ICMP トラフィックのプロキシに対応します。

TCP

プロキシが有効なとき、Gateway は常に TCP トラフィックを転送します。

デフォルトでは、TCP の接続試行は 30 秒でタイムアウトし、アイドル接続は 8 時間後に切断されます。

UDP

UDP プロキシは、VoIP、内部 DNS リクエスト、シッククライアントアプリケーションなどの UDP トラフィックを転送します。

HTTP/3 は UDP 上の QUIC プロトコルを使います。HTTP/3 トラフィックを検査するには、TLS decryption と UDP プロキシの両方を有効にします。Gateway は HTTP/3 接続を傍受し、オリジンサーバーへ HTTP/2 で接続します。そうしないと、HTTP/3 トラフィックは検査を迂回します。ブラウザーごとの動作については、HTTP/3 検査を参照してください。

ICMP（Internet Control Message Protocol）

ICMP プロキシにより、ICMP トラフィックは Gateway 経由でプライベートネットワークに届きます。たとえば、Cloudflare One Client ユーザーが内部サーバー IP に対して ping や traceroute などの診断コマンドを実行できます。

`cloudflared` 経由で ICMP トラフィックを許可する

Cloudflare Tunnel で ICMP プロキシを使うには、cloudflared ホストで ICMP トラフィックが cloudflared を通過できるように設定する必要がある場合があります。

ping_group_range に、cloudflared を実行しているユーザーの Group ID（GID）が含まれていることを確認します。

a. cloudflared プロセスの所有者を調べます。
```
ps -aux | grep cloudflared
```
```
johndoe         407  0.8  1.7 1259904 35296 ?       Ssl  21:02   0:00 /usr/bin/cloudflared --no-autoupdate tunnel run --token eyJhI...
```
b. cloudflared ユーザーの Group ID を取得します。
```
id -g johndoe
```
```
10001
```
c. ICMP の使用を許可されている Group ID を確認します。
```
sudo sysctl net.ipv4.ping_group_range
```
```
net.ipv4.ping_group_range= 0 10000
```
d. その範囲内のグループにユーザーを追加するか、ユーザーがすでに所属するグループを含むように範囲を更新します。ping_group_range を更新するには:
```
echo 0 10001 | sudo tee /proc/sys/net/ipv4/ping_group_range
```
e. すでに実行中のプロセスに変更を適用するには、cloudflared を再起動する必要があります。再起動後も変更を残すには、systcl パラメーターを更新します。
```
echo "net.ipv4.ping_group_range = 0 10001" | sudo tee -a /etc/sysctl.d/99-cloudflared.conf
```
複数のネットワークインターフェイス（たとえば eth0 と eth1）を使っている場合は、cloudflared が Internet 向きの外部インターフェイスを使うように設定します。
```
cloudflared tunnel run --icmpv4-src <IP of primary interface>
```

環境で ping_group_range パラメーターを変更し、cloudflared を実行しているユーザーの Group ID（GID）を含めます。

デフォルトでは、cloudflared Docker コンテナ ↗ はコンテナ内の nonroot というユーザーとして実行されます。nonroot は、使用しているベースイメージ ↗ に存在する特定のユーザーで、Group ID は 65532 にハードコードされています。

Gateway proxy を有効にする

Gateway proxy のトグルは、Cloudflare One Client デバイスからのトラフィックにだけ適用されます。PAC ファイルまたは Browser Isolation で送られたトラフィックは、この設定に関係なく Gateway が常にプロキシします。

Cloudflare ダッシュボード ↗ で Zero Trust > Traffic policies > Traffic settings を開きます。
Proxy and inspection settings で Allow Secure Web Gateway to proxy traffic をオンにします。
TCP を選びます。
（任意）用途に応じて UDP や ICMP も選べます。