オプションリファレンス
どちらのバイナリも、実行するモードに関わらず適用される少数の 共通フラグ(コネクション、TLS、パス、メトリクス)を取ります。各動作モードはさらにいくつかのモード固有フラグを追加します — そして重要なことに、モードはどのイングレスフラグを渡すか(--socks5、--http-connect、--gateway、--tproxy)によって クライアント側で選択 されます。サーバーは有効なすべての機能を単に提供し、何を使うかはクライアントが決めます。
以下の表は分割されています: まず共通フラグ、次にモードごとに 1 ブロック。各モード内では、サーバー側とクライアント側のフラグを別々に列挙します。
共通フラグ(全モード)
サーバー — mqproxy server …
| フラグ | 説明 |
|---|---|
--listen <ip:port> | (必須) MPQUIC コネクションを受け付ける UDP アドレス |
--token <token> | (必須) クライアントが提示すべき共有認証トークン |
--cert <path> / --key <path> | TLS 証明書/鍵 (PEM)。デフォルトは同梱のテスト証明書 |
--max-conns <N> | 同時 QUIC コネクション数の上限 (デフォルト 16、0 = 無制限)。超過した受信コネクションは拒否されます (CONNECTION_REFUSED) — 認証前 DoS ガード。 |
--cc <algo> | 輻輳制御: bbr (デフォルト) | bbr2 | cubic |
--scheduler <s> | マルチパススケジューラ: minrtt (デフォルト) | backup | wlb |
--qlog <dir> | xquic qlog を <dir>/server.qlog に書き出す |
--metrics-interval <sec> | パス単位の統計 (mq.conn / mq.path logfmt 行) を <sec> 秒ごとに定期ログ出力 (0 より大きいこと。省略で無効)。直近に受け付けた TCP とゲートウェイのコネクションをログ出力。 |
クライアント — mqproxy client …
| フラグ | 説明 |
|---|---|
--server <ip:port> | (必須) mqproxy サーバーの UDP アドレス |
--token <token> | (必須) 共有認証トークン |
--path <local ip> | パスをバインドするローカル IP — マルチパスアグリゲーションのために繰り返す (例: WiFi + LTE) |
--client-id <id> | 認証時に送るクライアント識別子 |
--cc <algo> | 輻輳制御: bbr (デフォルト) | bbr2 | cubic |
--scheduler <s> | マルチパススケジューラ: minrtt (デフォルト) | backup | wlb |
--qlog <dir> | xquic qlog を <dir>/client.qlog に書き出す |
--reconnect / --no-reconnect | トンネル喪失時に自動再接続 (デフォルト: 有効) |
--reconnect-max-backoff <sec> | 指数再接続バックオフの上限秒数 (デフォルト 30、0 より大きいこと) |
--keepalive-idle <sec> | これだけの秒数アイドルのとき QUIC PING を送る (デフォルト 30、0 = 無効。xquic の PING 間隔が約 15 秒のため 15 未満の値に追加効果はない) |
--metrics-interval <sec> | パス単位の統計 (mq.conn / mq.path logfmt 行) を <sec> 秒ごとに定期ログ出力 (0 より大きいこと。省略で無効)。プロキシコネクション (および --gateway 設定時はゲートウェイコネクション) をログ出力。 |
TIP
クライアントのイングレスフラグ (--socks5、--http-connect、--gateway、--tproxy) を少なくとも 1 つ渡すことが、実際にクライアントを稼働させる条件です — 以下のモードごとのブロックを参照してください。
TCP プロキシモード
1 TCP フロー → 1 MPQUIC 双方向ストリーム。TLS はアプリとオリジンの間でエンドツーエンドのまま (終端なし)。
サーバー: モード固有フラグなし — TCP プロキシは常に利用可能。
クライアント
| フラグ | 説明 |
|---|---|
--socks5 <ip:port> | ローカル SOCKS5 イングレス (TCP CONNECT)。UDP ASSOCIATE も提供 — UDP リレーモードを参照。 |
--http-connect <ip:port> | ローカル HTTP CONNECT イングレス (curl --proxy http://<ip:port> … で使用) |
HTTP ゲートウェイモード
1 HTTP リクエスト → MPQUIC 上の 1 H3 ストリーム。サーバーが委譲されたリクエストをオリジンに対して実行。サーバー側でデフォルト有効。
サーバー
| フラグ | 説明 |
|---|---|
--no-gateway | このサーバーの HTTP ゲートウェイモードを無効化 (デフォルト有効)。TCP プロキシのコアは動作し続け、ゲートウェイのオリジンブリッジだけが OFF になるため、クライアントの --gateway イングレスは通信相手を失う。 |
--origin-ca <pem> | オリジン TLS 検証用の追加 CA バンドル (プライベート CA/テスト)。検証自体は常に ON |
--request-metrics | ゲートウェイリクエストごとに 1 行の mq.req logfmt 行を出力 (method/status/target/ttfb/origin_protocol/cache/…)。オプトイン、デフォルト OFF。--metrics-interval とは独立。 |
--cache-max-bytes <N> | N バイトに制限されたインメモリのオリジンレスポンスキャッシュ (0 = OFF = デフォルト。例: 67108864 = 64 MiB)。リクエストごとに X-Mq-Cache でオプトイン。 |
--masquerade | 未認証 のゲートウェイリクエストに素の 404 (X-Mq-* ヘッダなし) で応答し、プローブ/スキャナにはフィンガープリント可能な 403 auth-failed ではなく一般的な HTTP/3 サーバーに見せる。認証済みリクエストには影響しない。ゲートウェイ専用、デフォルト OFF、インターネット公開サーバーに推奨。 |
クライアント
| フラグ | 説明 |
|---|---|
--gateway <ip:port> | HTTP ゲートウェイ fetch API (POST /_mqproxy/fetch) のローカル TCP アドレス。--socks5 の有無を問わず動作。 |
UDP リレーモード
1 UDP セッション → MPQUIC DATAGRAM。SOCKS5 UDP ASSOCIATE 経由で同じ --socks5 リスナー上に公開。mqproxy-tcp/1 コネクションに相乗り (--gateway のみのクライアントは利用不可)。
サーバー
| フラグ | 説明 |
|---|---|
--no-udp | このサーバーの UDP リレーモードを完全に無効化 — 機能は認証時にアドバタイズされず (クライアントには利用不可と見える)、試みられたセッションは拒否される。クライアント側のオーバーライドはない。 |
--udp-idle-timeout <sec> | UDP セッションのアイドルタイムアウト (デフォルト 60)。実効値は min(クライアント要求, この値) |
クライアント
| フラグ | 説明 |
|---|---|
--socks5 <ip:port> | TCP プロキシモードと同じリスナー — UDP ASSOCIATE を話す任意の SOCKS5 クライアントが使用。別途フラグは不要。 |
透過キャプチャモード
カーネルリダイレクト TCP → 不透明な MPQUIC ストリーム。アプリ設定不要。Linux + IPv4 のみ。TLS はデフォルトでエンドツーエンドに保たれ、--mitm を追加すると終端・検査する — TLS MITM モード を参照。
サーバー: モード固有フラグなし — 透過キャプチャはクライアント側のイングレス機構であり、サーバーは結果の TCP ストリームを SOCKS5 由来のものとまったく同様に扱う。
クライアント
| フラグ | 説明 |
|---|---|
--tproxy <ip:port> | 透過キャプチャイングレス (redirect または tproxy モード) のローカル TCP アドレス。透過キャプチャを有効化する。--socks5、--http-connect、--gateway、--tproxy のうち少なくとも 1 つが必要。 |
--tproxy-mode redirect|tproxy | カーネルキャプチャ機構 (デフォルト: redirect)。redirect — nft nat OUTPUT REDIRECT ターゲット。ローカルマシン自身の外向き TCP をキャプチャ。ソケットに IP_TRANSPARENT 不要。tproxy — nft mangle PREROUTING TPROXY ターゲット。ルータ/ゲートウェイ上で転送 LAN トラフィックをキャプチャ (標準的な Linux TPROXY。任意のポリシールーティングスタック、例: OMR で動作)。IP_TRANSPARENT のため CAP_NET_ADMIN が必要。 |
--tproxy-fwmark <n> | tproxy モードでのポリシールーティング用パケットマーク (デフォルト: 1。tproxy モードのみ)。 |
--tproxy-table <n> | tproxy 応答ルーティング用の IP ルーティングテーブル (デフォルト: 100。tproxy モードのみ)。 |
--tproxy-dport <port> | --setup-redirect ルールがキャプチャする TCP 宛先ポート (デフォルト: 443)。 |
--setup-redirect | 起動時に nft/ip rule のファイアウォールルールをインストールし終了時に削除 (root または CAP_NET_ADMIN が必要。デフォルト OFF)。単一ホストの自己完結用途向け。ルータ/ゲートウェイでは OFF のままにし、ルータスタック (例: OMR) にルールを管理させる。 |
--tproxy-uid <uid> | 外向きトラフィックがリダイレクトから除外される UID (デフォルト: プロセスの geteuid())。ループ回避に使用 — mqproxy 自身のトンネルコネクションが自分自身に再キャプチャされないように。 |
TLS MITM モード(クライアント専用)
キャプチャしたブラウザの TLS を偽造ホスト別リーフで終端し、HTTP/2 を話し、各リクエストをゲートウェイトンネルにマッピング。--tproxy が必要。HTTP/2 のみ。--mitm がない限り OFF。信頼モデルとセキュリティ姿勢は TLS MITM ガイド を参照。
サーバー: モード固有フラグなし — MITM はクライアント側のイングレスモードであり、結果のリクエストは通常のゲートウェイリクエストとしてサーバーに届く。
クライアント
| フラグ | 説明 |
|---|---|
--mitm | 透過キャプチャ経路で TLS を終端 (SNI ごとにリーフを偽造、h2 を話し、ゲートウェイトンネルへ供給) し、不透明リレーの代わりとする。--tproxy、--ca-cert、--ca-key が必要 で、BoringSSL アーカイブ付きでビルドされたバイナリ (scripts/build-xquic.sh) が必要。いずれかが欠けるとフェイルクローズの起動エラー。 |
--ca-cert <pem> | 署名 CA 証明書 (PEM)。オペレータの CA がデバイスに信頼されている必要がある。 |
--ca-key <pem> | 署名 CA 秘密鍵 (PEM)。暗号化されておらず、グループ/全体読み取り可能でないこと。O_NOFOLLOW/O_CLOEXEC で開かれる。 |
--ignore-host <host> | 不透明に スプライスするホスト (MITM をバイパス — 生の TLS をリレーしオリジンの本物の証明書をクライアントへ届ける。証明書ピンニングアプリ向け)。繰り返し可。 マッチは正規化された SNI に対して完全一致または先頭ドットサフィックス。 |
--ignore-hosts <a,b,c> | --ignore-host と同じだがカンマ区切りリスト。CLI と [Mitm] IgnoreHosts 設定エントリは和集合になる。 |
WARNING
同梱のテスト証明書はローカルテスト専用です。実運用では独自の --cert/--key と強力な --token を渡してください。