まずスプリットトンネリングを定義する

VPNのスプリットトンネリングは、端末で発生する通信のうち「特定の通信だけ」をVPN経由にし、それ以外はインターネット側（通常の経路）に流す考え方です。これにより、VPNの負荷や遅延を抑えたり、ローカルネットワークへの到達性を保ちやすくしたりできます。

一方で、通信の流れが混在するため、期待する挙動と実際の経路が一致しないと問題が起きます。たとえば「VPN経由だと思っていた通信が、実際は直通で出ていた」「逆に、直通でよいはずの通信までVPNに吸い込まれて遅くなる」といったズレです。

仕組みの簡単なモデル（何が分岐を決めるか）

スプリットトンネリングでは、端末が「この通信はVPN側に送るべきか」を判断して振り分けます。判断に影響しやすい要素は主に次の3つです。

1つ目は「宛先（行き先）ベース」の判定です。IPアドレスやドメインの条件に一致した通信だけをVPN経由にする設計が一般的です。 2つ目は「アプリ（またはプロセス）ベース」の判定です。あるアプリからの通信のみをVPN側に寄せる方式もあります。 3つ目は「DNS（名前解決）周り」の扱いです。名前解決がどの経路で行われるかで、結果的に接続先が変わったり、期待と異なる挙動になったりします。

この3つのどこかが想定と違うと、スプリットトンネリングは“便利”にも“厄介”にもなります。

起きやすい問題パターン

スプリットトンネリングで典型的に見つかるのは、次のような現象です。

1) アプリは動くのに、特定サービスだけ失敗する

VPN経由にする条件がサービスの通信形態と噛み合っていないと、ブラウザだけは開けるのに特定のAPIが失敗する、あるいは逆に一部がタイムアウトする、といった“部分的な不具合”になります。

2) アクセス元（見え方）や保護したい通信が混ざる

スプリットトンネリングは意図的に直通通信を残します。そのため、「すべての通信をVPNで保護したい」と考えていると、要件に対して設計が不一致になります。

3) DNSの結果が想定と違い、到達先が変わる

名前解決の経路や、キャッシュの影響で、同じドメインでも想定する接続先にならないことがあります。結果として、VPN経由のはずの通信が直通側の結果に引っ張られたり、逆に直通側がVPN条件に巻き込まれたりします。

4) ルールの優先順位や評価タイミングの違い

条件が複数ある場合、どれが優先されるか、いつ評価されるかで結果が変わります。設定を見ただけでは判断しにくいことがあるため、必ず実機の挙動確認が必要です。

解決策の考え方（設定を疑う順番）

解決策は、原因を「ルール」「名前解決」「経路」「再試行」の順に切り分けるのが効率的です。

1) まず“分岐ルール”が期待通りか

スプリットトンネリングの中心は、どの通信がVPN側に振り分けられるかという条件です。