増えているほうを見てください。アイコンが点いているかではありません。

ホームには同時にいくつか点いています。スイッチ、ポリシー、Data、一覧横のミリ秒です。目はそれを「繋がった」「繋がっていない」の一文にまとめます。誤読の起点です。四つの信号は独立です。どれかを別のものの別名にすると、あとの判断はすべて逆になります。完全な切り分けはマニュアルの Data 章にあります。本稿は Data の組だけを分解し、なぜアイコンより見る価値があるかを書きます。

スイッチが答えるのは、Network Extension が起きているかです。オンのまま、ステータスバーに VPN アイコンがあるのは、トンネルの層が生きていることだけです。ポリシーが答えるのは、トンネルに入ったあと、ルールをまだ問うかです。Config だけがルールを走らせ、Proxy は現在のレコードへ強制し、Direct は元経路へ強制します。一覧プローブが答えるのは、このホップが今プローブできるかです。Data が答えるのは、すでに起きたバイトが Direct か Proxy かです。四つの問いが一度の観察に重なり、第一問だけ見ると、「もう繋がったのになぜダメか」という、手が出せない結論になります。

VPN アイコンは特に騙しやすいです。スイッチに結びつき、ポリシーには結びつきません。Direct でもアイコンは点き、要求はセルラーや Wi-Fi の元経路で出て、ハイライトしたレコードを一切通りません。アイコンを「ノードを通った」証拠にすると、トンネルの存在で出口の使用を代用したことになります。トンネルの起動は トンネル を見てください。

Data にはカウンタが二つあり、名前は Direct と Proxy です。端末上に書かれ、すでに起きたバイトを数えます。プラン残量ではなく、第三者アカウントにいくら残っているかも見えず、リセットするとゼロから数え直し、対向のクォータは動きません。Data を「ノードにあと何 GB あるか」だと思うと、数字が大きいときも小さいときも、まったく無関係な判断になります。

一度のアクセスのあと、はっきり増えるのは片側だけであるべきです。現在のレコードに入るはずだと思うホストへ行き、すぐに見ます。Proxy が増えたなら、バイトはこのレコードに入りました。ページがまだ失敗するなら、問題は対向、名前解決、この App 自身がトンネルを拒んでいることが多く、「ノードを通っていない」ではありません。そこでルールを直すのは、すでにレコードを通ったと証明された経路を直すことです。Direct だけ増えたなら、要求は元経路に残されました。レコードへ入れるつもりなら、ポリシーが Direct か、Config 下でルールが先に DIRECT / REJECT と書いていないかを見てください。ルール です。

両方ほとんど動かないなら、要求はトンネルに入っていない可能性があります。スイッチが安定していない、システムに使える VPN 構成がない、別の VPN が枠を占めている。またはそもそも送信がない。機内モード、ポータルページが終わっていない、アプリがローカルキャッシュを回っている、などです。先にスイッチと システム を見て、それからレコードを疑ってください。

REJECT が当たると、成功した読み込みのようにカウンタを押し上げないことが多いです。アプリがエラー、Data が静か、は「ノードにトラフィックがない」に似ています。ポリシーを Proxy にしてもう一度アクセスすると、「ルールが捨てた」と「レコードのハンドシェイク失敗」が分かれます。前者は Proxy で通り、後者は Proxy でも失敗します。

二つのカウンタは左右を分けるだけで、「どのレコードか」は分けません。ハイライトを替える前の Proxy 数字は残り、行ごとにゼロにはなりません。カウントをある行に対応させるには、先にリセットし、その行を固定して一度アクセスします。十ページ開いてから合計を見ると、Direct も Proxy も動いていて、ある一回に対応できません。切り分けの粒度は「一度のアクセス」であり、「午後いっぱい」ではありません。

一覧の 1 行を選んだあと、Direct → Proxy → Config の順で切ります。同時にレコードを替え、FINAL を直し、コンテナを更新しないでください。Direct では端末アクセスとポータル認証ページが使えるはずです。ここでネットがなければ、先に Wi-Fi、セルラー、ログインページを処理し、レコードとは無関係です。Proxy でレコードへ通すはずのホストが開けるなら、トンネルとそのレコードはアプリ層で使えます。ここでも開けないなら、問題はレコードか対向であり、先にルールを直さないでください。Config は、Proxy がレコードを使えると証明したあとだけ調整し、一度に一つの条件、Data でカウンタがどちら側に立つかを見ます。

この順の用途は帰属です。Direct が失敗ならローカルネットを直します。Proxy が失敗ならレコードを直します。Config が失敗し Proxy が成功ならルールを直します。三段を同時にすると、画面上の毎回の変化を残りの二つの変数で説明でき、説明がありません。マニュアルは同じ順を Data 章に書いてあります。本稿が強調するのは、アイコンはこの三段のどれにも関与しない、ということです。

システム時刻が自動設定でないと、TLS はまとめて失敗し、スイッチはどのレコードでも異常に見え、プローブも一緒に壊れます。先に時刻の「自動設定」を入れてから、レコードの話をしてください。宛先が IPv6 で、ルールが IPv4 の IP-CIDR しか書いていないと、要求は FINAL に落ち、ルールが「ときどき効く」ように見えます。DNS を見てください。別の VPN が接続中なら、システムはこの拡張にトラフィックを渡さないことがあります。スイッチが点いていても、バイトが Shadowrocket に入ったことにはならず、Data の両方とも動きません。

アイコンが点き、プローブが小さく、ページが失敗し、Data は Direct だけ増える。四件は同時に真であり得ます。第一件だけ見ると、行動できない結論になります。四件を一緒に見ると、結論はポリシーかルールが今回のアクセスを元経路に残した、です。次の手は、その行を固定してポリシーだけ動かすことであり、新しいレコードを買うことでも、新しいリストを取り込むことでもありません。

もう一つのよくある誤読は、Data の Proxy 数字を「今日プランをいくら使ったか」にすることです。その数字が示すのは、端末が現在のレコード、または以前ハイライトしたレコードへ、かつて何バイト送ったかだけです。サイト別には分かれず、手動リセットしない限り日付でもゼロになりません。レコードを替えてアクセスすると、新しい増分は古い Proxy に重なります。「この行は使えるか」に答えるには、先にリセットし、一度だけアクセスし、どちら側が動いたかを見ます。リセットせず、連続して行を替え、複数 App を開いたままでは、どの行も有罪にできない雑な合計になります。