接続トラブルシューティング · Clash 技術ブログ

FlClash v0.9.2：終了後のプロキシ保持と復元

Windows で FlClash を終了した後もプロキシが残る、または元のプロキシが無効になる場合は？v0.9.2 が今回の起動で設定を変更したかを切り分け、システム設定を記録してから正常に終了し、元の値に戻して実際の通信を確かめます。

本文を読むブログへ戻る
  • FlClash
  • v0.9.2
  • システムプロキシ
  • Windows
  • 正常な終了
目次
公開日
読了時間の目安
約 8 分

Windows で FlClash を正常に終了してもシステムプロキシが有効なままなら、必ずしも解除に失敗したとは限りません。元のプロキシが無効になった場合も、アプリが以前の設定を保存していたのに復元できなかったとは限りません。まず誰が設定したものかを確認し、残す、無効にする、元の値に戻す、のどれが必要か判断しましょう。

終了後にプロキシが残る場合と、無効になる場合を分ける

FlClash v0.9.2 の正式リリース記録には、このアプリが設定していないシステムプロキシを保持する変更が記載されています。この記事は Windows 10/11 と、このバージョンのシステムプロキシスイッチ、正常終了の動作に範囲を絞ります。TUN、WinHTTP、ターミナルの環境変数、アプリ独自のプロキシ設定は、それぞれ別のものです。

終了前後の実際の設定から、確認する点を絞る

確認できた状態最初に行うこと
今回の起動では有効化を試していない、またはすでに無効化に成功しており、終了後も元のプロキシが残る今も必要な元のサーバーやスクリプトかを確認します。スイッチが有効なままという理由だけで、設定を消さないでください。
FlClash のプロキシを有効にした後、終了しても元の社内プロキシや PAC が戻らないこのバージョンに元の値への自動復元の保証はありません。事前の記録に従って、必要な設定に戻します。
FlClash は終了しているが、手動プロキシは以前のローカルポートを指したまま有効で、リクエストが失敗する本当に正常終了したか、システム設定と失敗時のログを確認し、元のネットワークに必要な設定に戻します。
ブラウザは使えるが、ターミナルや特定のアプリだけ失敗するそのプログラムがどこからプロキシ設定を取得するかを別に調べます。システムプロキシのスイッチだけでは、すべてのプログラムの状態は分かりません。

v0.9.2 が保持するのは、どの設定？

このバージョンはシステムプロキシの有効化処理に入ると、解除が必要という記録を残します。終了時は、その記録が残っている場合だけ無効化します。先に無効化に成功すれば記録は消えるため、今回一度も有効化を試していない場合と同様、終了時に重ねて解除しません。Windows の現在のプロキシ設定を読み、設定した主体を判定する仕組みではありません。

対象バージョンのソースコードでは、この記録は _applied と呼ばれ、startProxy を呼ぶ前に true になります。つまり、有効化を試したことを示すだけで、システムプロキシの書き込み成功を証明するものではありません。有効化と無効化のどちらの失敗でも、update system proxy failed というログが残る場合があります。

Windows の stopProxy は WinINet を使い、接続オプションを PROXY_TYPE_DIRECT に切り替えます。以前のサーバー、PAC、すべての例外を保存して復元する処理ではありません。システムプロキシの解除と、元の社内ネットワーク設定への復元は別の操作です。

自分でスイッチを押したかどうかだけでも判断できません。このバージョンの systemProxy の初期値は true で、保存済みの自動実行などの状態によって、有効化処理に入る場合があります。区別すべきなのは、クリックした記憶ではなく、今回のプロセスが設定変更を試したかどうかです。

Windows の元の値と FlClash の現在の状態を控える

元に戻せるよう、比較前の状態を残す

  1. システム設定を記録する

    Windows の設定で「ネットワークとインターネット → プロキシ」を開きます。自動検出、設定スクリプト、手動プロキシの各スイッチと、スクリプトのアドレス、サーバー、ポート、例外をそれぞれ控えてください。元々プロキシを使っていない場合も、その状態を記録します。

  2. アプリの状態と通信の処理方法を記録する

    実際の FlClash のバージョンが v0.9.2 であることを確かめ、現在の設定、実際のプロキシポート、ダッシュボードの「システムプロキシ」と「TUN」の状態、「自動実行」の設定を記録します。実際の値の代わりに、既定のポート番号を書き留めないでください。

  3. ほかの機能と分けて検証する時間を取る

    システムプロキシは、通信を中断できる時間に検証します。TUN の元の状態を記録してから「TUN」を一時的にオフにし、同じ Windows の設定を自動で書き換えるほかの機能を止めます。必要な元のプロキシサービスは、動かしたままで構いません。

信頼できる元の値が分からない場合は、まず現状と記録を残し、元のプロキシツールや組織が用意した復旧方法を使ってください。知らないサーバーの値を入れないでください。Windows の設定が組織によって管理され、変更できない場合は、既定の管理者の手順に従います。レジストリ項目を削除して制限を回避しないでください。

今回設定を変更していないとき、元のプロキシが残るか確認する

新しいプロセスで、条件をはっきりさせて比較する

  1. まず FlClash のシステムプロキシをオフで保存する

    状態を把握できる環境で FlClash の「システムプロキシ」をオフにし、タスクトレイの「終了」で正常に終了します。スイッチをオフにする操作自体が、今回のプロキシを解除する場合があります。先に元の値を記録してあることを確認してください。

  2. 必要な元のプロキシ設定に戻す

    FlClash の終了後、元のツールまたは Windows のプロキシ画面で、事前に確認した自動検出、スクリプト、手動プロキシの設定に戻し、実際のリクエストを試します。元々直接接続が許されていた場合は、その状態に戻します。プロキシが必要な業務では、直接接続できても同等の復旧とは見なせません。

  3. 開き直し、システムプロキシを有効にせずに使う

    保存されたシステムプロキシがオフであることを確認し、自動実行の状態にも注意しながら、確認中はこのスイッチを有効にしません。同じ対象へのリクエストで元の経路を確認してから、タスクトレイの「終了」を選びます。ウィンドウを閉じるだけでは最小化される場合があり、この操作の代わりにはなりません。

  4. Windows の設定と実際の通信を比べる

    自動検出、設定スクリプト、手動プロキシのスイッチ、アドレス、ポートが、記録した状態を保っているか再確認し、同じリクエストを試します。設定が変わっていた場合は、前後の時刻、アプリの状態、ログを残してください。アイコンだけで判断しないでください。

v0.9.2 の正常終了時の保護は、対応する処理に限られます。元のプロキシが変わらず、引き続き必要なら、その設定を残します。それでも無効になる場合は再現条件を記録してください。一度の結果から、ほかのバージョン、すべての終了方法、ほかのソフトウェアまで保護されるとは判断できません。

今回設定を変更した場合は、必要なネットワークの元の値に戻す

FlClash 自身のシステムプロキシを検証する場合は、まずアプリが動作していることを確認して実際のポートを控え、TUN がオフのままであることを確かめてから「システムプロキシ」をオンにします。Windows の設定が FlClash のローカルアドレス 127.0.0.1 と実際のポートに対応しているか確認してください。ボタンがオンに見えるだけでは、書き込み成功は証明できません。

無効化し、元に戻して確認する

  1. 今回のプロキシ設定を解除する

    「システムプロキシ」スイッチで無効にするか、タスクトレイの「終了」で正常終了し、処理が終わるのを待ちます。update system proxy failed が出た場合は、ログと Windows の現在の値を残してください。繰り返し切り替えて、前後の違いを分からなくしないでください。

  2. 元々必要だった設定に戻す

    元々直接接続していた場合は、手動プロキシを元のオフの状態に戻します。別のサーバーや PAC を使っていた場合は、自動検出、スクリプト、手動プロキシそれぞれのスイッチと、アドレス、ポート、例外を事前の記録どおりに戻すか、元のツールで設定し直します。終了すれば自動で元に戻ると思い込まないでください。

  3. 実際のリクエストを個別に確認する

    元に戻した同じネットワークから元の対象へアクセスし、想定したプロキシまたは直接接続が使われているか確認します。特定のプログラムだけ失敗する場合は、そのプログラムの設定を別に調べてください。WinHTTP、環境変数、すべてのプロキシ設定を一度にリセットしないでください。

FlClash が設定を変更した後、別のツールがシステム設定を書き換えても、今回のプロセスの記録が、自動で信頼できる「現在の設定主体」の判定になるわけではありません。設定を書き換える操作は一つずつ完了させてから、必要な元の値に戻します。複数のクライアントを自動調整する仕組みとは考えないでください。

どの結果を確認できれば、作業を終えてよい？

終了と復元の確認事項

  • アプリの正確なバージョンと実際のポート、Windows の自動検出、設定スクリプト、手動プロキシの元の値を記録した。
  • 今回一度も設定変更を試していない場合、変更を試した場合、有効化に失敗した場合を分けた。クリックの記憶だけで判断していない。
  • タスクトレイから正常終了した。ウィンドウを閉じるだけの操作、タスクマネージャーでの強制終了、インストーラーの解除処理と混同していない。
  • 終了または無効化後の Windows 設定が実際の用途に合っている。元の自動検出、社内サーバー、PAC、例外を記録どおりに戻した。
  • 同じ対象への実際のリクエストが成功した。ターミナル、TUN、アプリ独自のプロキシに別の異常がある場合は、個別に証拠を残した。

インストールとアンインストールは別の処理です。このバージョンのインストーラーは、--clear-stale-proxy 引数を付けたプロセスを呼び出し、残ったプロキシを処理します。この記事で扱う、通常の終了時のキュー処理とは異なります。保護を検証するためにこの引数を実行しないでください。強制終了やクラッシュでも、正常な解除処理が済んだとは判断できません。

設定がまだおかしいとき、どう戻して報告する？

まず今回の比較を止め、記録しておいた Windows の設定、FlClash のシステムプロキシと TUN の元の状態、ほかの一時的な変更を元に戻します。そのうえで、通常の通信と、元のプロキシが必要な対象への接続を確認してください。プロキシサービス自体が使えない場合は、まずそのサービスを復旧します。同じ無効なアドレスを入れ直すだけでは足りません。

機能を使うために更新が必要な場合は、アプリデータと Windows の元の値を独立してバックアップし、プロジェクトの正式な配布元から更新します。更新後に互換性問題が起きた場合は、サポートされている元の手順で、該当バージョンとバックアップに戻します。バージョンを戻しても Windows 側の設定は自動復元されません。データのコピーが一つしかない場合、そのディレクトリを複数のバージョンで共用しないでください。

プロジェクトには、クライアントとシステムの正確なバージョン、自動実行の有無、システムプロキシと TUN の状態、今回のプロセスで有効化した経緯、正常終了の方法、前後のアドレスと失敗時刻を報告します。公開する資料では、非公開のサーバー、PAC の認証情報、サブスクリプションのトークンを隠してください。元のログとバックアップは手元の端末に残します。

参考資料