想定する症状と、この記事の位置づけ

毎年のように話題になるのが、新しい iOS のパブリックベータや正式版へ上げた直後に、特定の VPN／プロキシ系アプリだけが「接続はオンなのにブラウザもメッセージも全部タイムアウト」「HTTPS の証明書が信頼できないと出る」「Wi‑Fi では再現しないがセルラーだけ不安定」といった形で壊れたように見える現象です。検索クエリでも iOS 26 Clash のように、バージョン番号とクライアント種別を一緒に打つ人が一時的に増えます。本稿はそのホットなタイミング向けの切り分けとして、サーバ設定の細部よりも端末側の権限と OS スタックを五段階で押さえます。

利用できるクライアントの名称や App Store の扱いは時期・地域で変わります。ここでは商標に依存せず、「Clash コア互換のモバイル実装一般」として読めるようにしています。また、サブスクリプション URL の取り込み失敗やモバイル回線特有の挙動は、別角度でまとめたiPhone サブスク・セルラー切り分けの記事と役割が分かれます。今回はOS 更新直後に一気に表面化しやすい層に絞ります。

ステップ1：ルート証明書・プロファイル信頼と HTTPS エラー

MITM や独自 CA を伴う構成では、構成プロファイル経由で渡したルート証明書を「信頼済み」に切り替える手順が iOS では必須です。アップデート後にプロファイル一覧は残っていても、信頼設定がリセットされたり、古いプロファイルと新しいアプリビルドの組み合わせで警告だけが増えたりすることがあります。設定 > 一般 > VPN とデバイス管理で該当プロファイルを開き、証明書の状態を確認してください。続けて設定 > 一般 > 情報 > 証明書信頼設定（表示される端末のみ）で、ルートをオンにし直すのが定石です。

警告文面が「中間証明書の欠落」のように読める場合は、プロファイルの再配布だけでは足りず、サーバ側チェーンの更新が必要なこともあります。とはいえ、ユーザー側でまず試せるのは「一度プロファイルを削除し、アプリの案内に従ってクリーンに入れ直す」ことです。複数の VPN アプリを試したあとでは、古い VPN 構成が残って新しいトンネルと競合している例も多いので、使わない構成は整理します。企業端末で MDM が証明書を上書きしている場合は、個人の切り分け以前に管理ポリシーが優先される点にも留意してください。

ステップ2：ローカルネットワーク権限と「見えているのに繋がらない」

iOS はバージョンを重ねるごとに、ローカルネットワークへのアクセスをアプリ単位で制御する流れが強まっています。名称から自宅 LAN のファイル共有だけに思えますが、実際にはmDNS や同一セグメントの検出、開発者向けのデバッグ用途など、プロキシ実装の内部動作と交差する場面があります。アップデート後に権限ダイアログの文言やデフォルトが変わると、以前は許可していたつもりが実際にはオフに戻っている、というケースも起こり得ます。

切り分けでは設定 > プライバシーとセキュリティ > ローカルネットワークを開き、対象アプリのトグルを一度オフにしてからオンに戻す、あるいは逆に一時的にオン固定で挙動差を見ます。LAN 上の別マシンへプロキシを向けている構成では、この権限と合わせて同一 Wi‑Fi か、ゲスト VLAN に隔離されていないかも確認してください。ここが「権限はあるのに到達しない」状態を生む典型です。ローカルネットワーク権限は検索でも語られるキーワードなので、症状のメモに含めておくと再現条件の共有がしやすくなります。

ステップ3：DNS、iCloud プライベートリレー、構成プロファイル DNS

プロキシがオンでも、名前解決だけが別ルートに逃げていると、ルールは正しくても接続先 IP が期待とズレ、結果として「全部遅い／一部だけ開かない」に見えます。iOS 側では、iCloud プライベートリレーや、キャリア・プロファイル由来の DNS、VPN が付与する DNS の優先順位が絡みます。大バージョン更新の直後は、これらの優先順位やトグル位置の UI が変わり、ユーザーが気づかないうちに二重の DNS オーバーライドが起きていることもあります。

切り分けの実務では、まずプライベートリレーを一時オフにして再現性を比較します。次に、設定内の DNS や VPN プロファイルに DNS が埋め込まれていないかを見ます。Clash 側の dns や fake-ip の考え方はデスクトップと共通の部分が大きいので、基礎の言語化はYAML・ルールと Fake-IP の解説へ委ね、モバイルでは「OS が握っている DNS とクライアントが握っている DNS が衝突していないか」を重点的に見てください。モバイル回線だけ怪しい場合は、IPv6 の扱いやキャリアのプロキシ検出が絡むこともあるため、Wi‑Fi とセルラーを必ずペアで記録します。

ステップ4：VPN 構成の再発行・競合排除・再起動順序

Packet Tunnel 系の実装では、VPN 構成の追加・削除の順序が安定性に効きます。OS を跨いだあと、古い構成 ID が残り、アプリの UI 上はオンでもカーネル側のトンネルが張れていない——という状態は珍しくありません。まず設定 > 一般 > VPN とデバイス管理 > VPNで、同種のアプリが複数ないか確認し、使わないものはオフまたは削除します。そのうえでアプリ側から「構成の再インストール」に相当する手順（表現はアプリごとに異なります）を踏み、端末の再起動まで含めて一度リセットすると、再現が消えることがあります。

ショートカットやフォーカス連動の「通信制限」、低データモード、省電力モードは、更新タイミングで既定値が変わったように感じることがあります。切り分けの間は、これらをできるだけシンプルな状態に戻して試してください。また、複数のセキュリティアプリや広告ブロッカーが VPN スロットを奪い合う構成では、同時にオンにできるのは基本的に一つという前提に立ち、役割を分担させます。

ステップ5：回線別・時間帯別の記録と「プロキシ断線」の言語化

最後に、観測ログを短く残します。Wi‑Fi のみ／セルラーのみ／両方、ベータ前後のビルド番号、証明書警告の有無、DNS を変えたときの差、ローカルネットワーク権限を切り替えたときの差——この五項目がそろうと、コミュニティやサポートへ投げる情報の質が一気に上がります。「プロキシ断線」と一言でまとめがちですが、実際には TLS 失敗なのか、名前解決なのか、トンネル確立前に落ちているのかで打ち手が変わります。

ベータ期間中はアプリ側も追従アップデートが続くため、クライアントを最新に寄せたうえで再検証するのが筋です。安定版 iOS に戻して再現が消えるなら、ベータ固有のリグレッションに近い可能性が高く、フィードバックアプリからの報告や、利用中のクライアントのリリースノート確認が次の一手になります。長期的には、ルールやノード品質の話に戻るので、サブスクや遅延の話題は引き続き既存の iPhone 向け記事と併読すると全体像がつながります。

まとめ

大バージョンの iOS 更新は、利用者の検索行動も一時的に「バージョン番号＋クライアント名」へ寄るタイミングです。現場では証明書とプロファイル信頼、ローカルネットワーク、DNS と OS 付帯機能、VPN 構成の競合、回線と記録の五段に分けると、ルール YAML をいじる前に手戻りが減ります。同じ「繋がらない」でも、TLS 警告なのか名前解決なのかを先に分けるのが早道です。

クライアントの入手と更新履歴の確認は、配布元ごとに整理したダウンロードページから進めると、コアと UI の対応関係を追いやすいです。オープンソースのリポジトリは仕様確認に役立ちますが、実行ファイルの主な入手経路としてサイト側の案内を使うと取り違えが減ります。→ 無料で Clash をダウンロードし、iOS 26 系での再検証を始める