Happ Proxy：Happ 用プロキシ — 有効化と設定の方法

Happ Proxy とは何か、プロキシモードの仕組み

Happ Proxy は Happ クライアントのトランスポート層であり、アプリのトラフィックを選択したサーバーまでの暗号化トンネルに包み込みます。「すべてのトラフィックを一つの VPN へ」という従来の方式とは異なり、Happ 用プロキシはピンポイントで動作します。デバイス上にローカルなプロキシエンドポイントを立ち上げ、あらかじめ定めたルールに従って、どの接続をサーバー経由で送り、どれを直接のまま残すかを判断します。まさにこの選択性こそが、Happ を単なる「接続する」ボタンではなく、設定のためのツールにしているのです。

内部では Happ は最新のトランスポート — VLESS、VMess、Trojan、Shadowsocks — をサポートしており、これらはサブスクリプションリンクを通じてアプリに渡されます。クライアントはサブスクリプションを解析し、ノードのパラメータ（アドレス、ポート、暗号化方式、TLS/Reality、SNI）を抽出して、プロファイルとして待機状態に保ちます。再インストールなしでプロファイルを切り替えられ、変わるのはアクティブなルートだけです。

プロキシモードの実用的な意味は、安定性と制御にあります。銀行アプリをトンネルの外に通すのか、ストリーミングを目的の地域のサーバー経由にするのかを、あなた自身が決められます。さらにこのロジックの上に、後述する除外リストや split tunneling、そして特定の用途に合わせたサーバー選定が積み重なっていきます。

Happ 用プロキシを有効にする：手順ごとの設定

ステップ 1 — サブスクリプションを追加します。Happ を開き、プロファイル/設定のセクションに移動して、サブスクリプションリンク（happ://、vless:// 形式、またはサブスクリプションへの https リンク）を貼り付けます。クライアントが利用可能なノードのリストを取り込みます。リンクは一つでもノードが複数あるのは正常です。サブスクリプションには通常サーバーのプールが含まれています。

ステップ 2 — ノードとプロトコルを選びます。初回起動には、地理的に最も近いサーバーで VLESS + Reality または Trojan を選んでください。これらは不安定なネットワーク上でも接続をよく維持します。ノードをタップしてアクティブにし、遅延テスト（ping）を実行します。これは単なる緑のチェックマークではなく、実際の応答を示します。

ステップ 3 — トンネルを有効にします。接続ボタンを押します。Android ではシステムが VPN インターフェースの作成許可を求めます。これはプロキシがトラフィックを傍受するための正規の仕組みです。Windows では完全な TUN モードのために Happ Utility（/proxy-utility/ のセクションを参照）を使用し、これがシステムのネットワークアダプターを立ち上げます。

ステップ 4 — ルートを確認します。任意の IP チェックサービスを開き、アドレスがサーバーのアドレスに変わっていることを確認してください。IP が以前のままなら、トラフィックはトンネルの外を通っており、ルーティングモードとアプリの権限を確認する必要があります。

ルーティングと除外リスト（split tunneling）

Happ の除外リストは、どのドメインやアプリがトンネルを迂回し、どれがサーバー経由で通るかを決めます。これはきめ細かな設定の核心です。適切に作られたリストはサーバーの負荷を下げ、ローカルサービスを高速化し、無駄な切り替えをなくします。リストは二つのロジックで扱えます — 「既定はプロキシ経由、除外は直接」か、その逆です。

アプリ単位の split tunneling は Android と Windows の TUN モードで利用でき、トンネルを有効または無効にする特定のアプリを指定します。典型的なシナリオは、銀行やローカルバンキング、地域の変更に敏感なアプリをトンネルから外し、メッセンジャーやメディアはサーバーに残すというものです。モードの詳しい解説は /split-tunneling/ のページにあります。

ドメインのルーティングにはリストによるルールを使います。geosite/geoip セットを使えば、一つのルールでカテゴリ全体（例えばローカルリソース）を直接に送り、それ以外はすべてサーバー経由にできます。まず既製のセットから始め、必要に応じてピンポイントの除外を追加していきましょう。そうすればリストは管理しやすいまま保たれ、何百もの手動行が積み重なるゴミ捨て場になりません。

リストを編集するたびに接続を再起動し、実際のドメインで結果を確認してください。ルールは優先順位順に適用されます。より具体的なルールを一般的なルールより上に置く必要があります。さもないと広範なルールが先にトラフィックを横取りしてしまいます。

速度と接続の安定性の最適化

Happ 用プロキシの速度は三つの要素で決まります。サーバーの近さと混雑度、選んだトランスポート、そしてネットワークのパラメータです。まずサーバーから始めましょう。サブスクリプションの複数のノードで ping を回し、最も「見栄えの良い」ものではなく、応答が最も安定したものを選びます。用途に合わせたノード選定は /servers/ のセクションで解説しています。

トランスポートはパケットロスへの耐性に影響します。モバイル回線や干渉のある Wi-Fi では、UDP ベースの方式（例えば QUIC/Reality 上の接続）がより均一な速度を出すことが多く、厳格な企業ネットワークでは TCP+TLS がよく持ちこたえます。切断が繰り返される場合は、プロファイルでプロトコルを切り替えて比較してみてください。

ネットワークレベルのきめ細かな調整は、速度が「変動する」ときに役立ちます。MTU の縮小（問題のある回線では 1400 前後まで）はフラグメンテーションをなくし、mux/多重化の有効化は多数の短い接続におけるオーバーヘッドを減らします。パラメータは一度に一つずつ変更して測定してください。さもないと何が効いたのか判断できません。

Windows では TUN モードの安定性とシステムトラフィックの正しい傍受を Happ Utility が担います。常に更新しておきましょう。サードパーティのネットワークフィルターや古いアダプターのドライバーとの競合は、性能低下のよくある原因です。暗号化と接続保護に関する話題は /security/ のセクションにまとめてあります。

診断：プロキシが接続できない場合

接続が確立しない場合は、簡単なことから複雑なことへと進めていきましょう。まずサブスクリプションを更新します。プール内のノードが変わっており、クライアントが古いアドレスを保持している可能性があります。「サブスクリプションを更新」を一度押すだけで、プロファイルを作り直さずに最新のパラメータが取り込まれます。

システムの時刻とタイムゾーンを確認してください。TLS/Reality を使うトランスポートは時計のずれに敏感です。数分の食い違いでハンドシェイクが壊れ、外見上は「サーバーが応答しない」ように見えます。時刻の自動同期を有効にしましょう。

ノードとプロトコルを変更します。あるサーバーが沈黙していて、同じサブスクリプションの隣のノードが動くなら、問題はクライアントではなくノード側にあります。すべてが沈黙している場合は、プロバイダーのネットワークが原因であることが多いです。別のトランスポート、SNI の変更、あるいは確認のためモバイルインターネット経由の接続を試してみてください。詳しいトラブルシューティングのチェックリストはサポートのセクションにまとめてあります。

最後に、ルーティングと除外リストを確認します。ルールの誤りや広すぎる除外は、すべてのトラフィックをトンネルの外へ逸らし、「プロキシが動かない」という錯覚を生みかねません。ユーザー定義のルールを一時的に無効にし、基本の接続が生きていることを確認したうえで、ルールを一つずつ戻していきましょう。