Happ の除外リストと split tunneling：トラフィックのルーティング管理

Happ における split tunneling と除外リストとは

split tunneling とは、クライアントが送信トラフィックを2つの流れに分ける方式です。一方はプロキシサーバー経由で、もう一方はプロバイダーを通じて直接流れます。この分離は Happ のリスト、つまりルールの集合によって管理され、除外の対象となるドメイン・IP サブネット・アプリケーションを明示的に指定します。ルールに該当しないものはすべてデフォルトのポリシーで処理されます。

Happ にはリストを構成する2つの根本的に異なるアプローチがあります。1つ目は除外モード（bypass）で、リストに列挙したもの以外のすべてのトラフィックがプロキシを通ります。銀行アプリ、ローカルサービス、リージョン変更に敏感なサイトをトンネルから外すのに便利です。2つ目は包含モード（proxy-only）で、すべてが直接流れ、指定したリソースのリストだけがサーバー経由でルーティングされます。モードの選択によって、デバイス上の Happ バイパスのロジック全体が決まります。

技術的には、ルールはプロファイルの設定に保存され、ルーティングエンジンによってセッションを再接続することなくリアルタイムで適用されます。つまり、リストの変更はほぼ即座に反映され、トンネルを完全に作り直す必要はありません。このモデルを理解することが、速度と安定性を細かく調整するための基礎になります。

Happ の除外リストにサイトを追加する方法

ドメインを追加するには、アクティブなプロファイルを開き、ルーティング（Routing / ルール）のセクションに移動します。ルールの追加をタップし、example.com の形式でドメインを指定します。http プロトコルや末尾のスラッシュは付けません。すべてのサブドメインをカバーするには、domain:example.com のようなマスクや接尾辞表記を使うと、app.example.com と cdn.example.com が自動的に1つのルールに含まれます。

ルールにはアクションを指定します：proxy（サーバー経由に送る）、direct（直接流す）、block（接続をブロックする）。ドメインとアクションの組み合わせこそが Happ バイパスの挙動を形成します。速度のために重い動画サービスをトンネルから外したい場合は direct を、特定のリソースへサーバー経由で安定してアクセスしたい場合は proxy を設定します。

ドメインのほかに、Happ のリストには IP アドレスや CIDR サブネット（例えばローカルネットワーク用の 10.0.0.0/8）、GEO ラベル（geoip:ru、geosite:category-ads）を登録できます。サブネットは企業リソースや NAS に、GEO ルールは何百ものドメインを手動で列挙する代わりにカテゴリ全体を一括で記述するのに役立ちます。

保存後はルールの順序を確認してください。エンジンはルールを上から下へ適用し、最初に一致したところで停止します。上位にある広すぎるルールは下位のより正確なルールを覆い隠すため、具体的なドメインは広いマスクや GEO カテゴリの上に置いてください。

リストからサイトやルールを削除する方法

削除は同じルーティングのセクションで行います。ルール一覧から目的の行を見つけ、コンテキストメニュー（モバイルクライアントでは左スワイプ、デスクトップ版ではゴミ箱アイコン）を呼び出して削除を確定します。ルールはアプリを再起動することなくアクティブな設定から消えます。

削除後もリソースが以前と同じ挙動を続ける場合、原因はほぼ必ず DNS キャッシュか重複したルールにあります。同じドメインが別のリストやより広いマスクに含まれていないか確認してください（例えば個別のサイトが geosite カテゴリに該当していた可能性があります）。重複するルールを取り除き、プロファイルを再接続して DNS キャッシュをリセットします。

大量のクリーンアップには、1行ずつ編集するより設定のインポート/エクスポートを使う方が便利です。現在のルールをエクスポートし、外部エディタで routing ブロックを編集して、再びインポートします。これにより、孤立したルールを誤って残すリスクが減り、大きな Happ のリストの管理が容易になります。

重要なルールを削除する前には、プロファイルのバックアップを取ってください。保存済みバージョンへのロールバックは数秒で済みますが、数十のドメインから手作業で組み立てたリストの復元は30分がかりの作業になります。

アプリごとのルーティングとリストの購読

ドメインベースのルーティングに加えて、Happ はアプリケーションごとの分割（per-app）にも対応しています。モバイルプラットフォームでは、どのアプリがトンネル経由で、どのアプリがプロキシを迂回して直接流れるかを指定します。これはドメインルールの上に乗る独立したレイヤーです。例えば、メッセンジャーをまるごとサーバー経由に向け、銀行クライアントをドメインリストに触れずにトンネルから外すことができます。

負荷の高いシナリオでは、既製のルーティングリスト購読を使いましょう。これはクライアントが定期的に取得・更新する、ルールセットを含む外部 URL です。こうすることで、カテゴリ（広告、トラッカー、リージョンリソース）の最新状態を手動編集なしで維持できます。購読は、リンクと更新間隔を指定してルールソースを追加することで接続します。

レイヤーは意図をもって組み合わせてください。まず per-app がアプリのトラフィックがそもそもトンネルに入るかどうかを決め、次にドメインルールと購読がトンネル内でどのサーバーまたは直接ルートを適用するかを決めます。この階層構造により、レイヤー間の衝突のない予測可能な Happ バイパスが実現します。

アクティブな購読の数は最小限に保ってください。各購読がルーティングエンジンに数千のルールを追加し、リスト間の重複が接続の解析時間を増やし、非力なデバイスではセッション確立を遅くする可能性があります。

適切なリストによる速度と安定性の最適化

適切に構成された除外リストは速度に直接影響します。ローカルで高負荷なトラフィック（ストリーミング、OS の更新、ポリシーに応じたトレント）をトンネルから外すことで、プロキシチャネルの負荷を軽減し、本当に重要な接続の遅延を減らせます。これは単に何かを回避する手段ではなく、最適化の要となる手法です。

ルールの順序と具体性が解析のパフォーマンスを左右します。ピンポイントなドメインルールは広い GEO カテゴリよりエンジンにとって軽いため、よく使うリソースは個別の行として上位に配置します。Happ のリストから古くなった重複エントリを定期的に掃除してください。肥大化したルールセットは新しい接続ごとの確立を遅くします。

診断には組み込みの接続ログを使いましょう。特定のドメインに対してどのルール（proxy、direct、block）が作動したかを示してくれます。リソースが意図と違うルートを通っている場合、どのルールが接続を横取りしたかが即座に分かり、リスト全体を手当たり次第に探ることなく、まさにそのルールを修正できます。

変更後の最終チェック：いくつかのテスト用リソースを開き、ログでルートを照合し、遅延を計測します。安定した設定とは、各ルールに根拠があり、順序が予測可能で、リストと購読の間に不要な重複がないものです。