目次
Clash の元の設定はそのまま共有せず、まずトラブルシューティング用のコピーを作成する
完全な YAML、ログ、スクリーンショットには、サブスクリプションの token、ノードのパスワード、コントローラーの secret、内部ネットワークのアドレスが同時に含まれることがあります。復元用の元のバックアップは、自分の暗号化ストレージへ保存してください。他人へトラブルシューティングを依頼する際は、元のファイルで数個のフィールドを安易に塗りつぶすのではなく、空のファイルから最小限のコピーを作成します。
共有前に一項目ずつ探す
| 場所またはフィールド | 公開される可能性がある情報 | 処理方法 |
|---|---|---|
| サブスクリプション URL のクエリパラメーター | 設定全体を直接取得できる token | 完全な URL を削除し、ドメインとステータスコードだけを残す |
| proxies のノード | server、UUID、password、PSK、private-key | example.com と REDACTED をプレースホルダーとして使用する |
| external-controller / secret | ローカルの制御アドレスと API キー | フィールドの構造は維持し、実際の値を置き換える |
| ログとスクリーンショット | Authorization、Cookie、ユーザー名、QR コード | 無関係な画面を切り取り、もう一度全体を読む |
| LAN と会社のドメイン | 内部ネットワークのアドレス、ホスト名、構成 | 問題の説明に必要な最小範囲だけを残す |
完全なバックアップと問い合わせ用の添付ファイルは、最初から分けて作成する
完全なバックアップは復元に使うため、実際のサブスクリプション、ノード、ローカルオーバーライドを残す必要があり、自分が管理する暗号化ストレージにのみ保存できます。トラブルシューティング用のコピーは他人が読むものであり、新しいファイルから始め、問題の再現に必要なフィールドだけを追加してください。長い URL、Provider header、スクリプトの引数は見落としやすいため、元のファイルから順に削除する方法は避けてください。
バックアップのファイル名には、クライアント、カーネル、日付を含めることができます。例：verge-macos-2026-07-16-private.zip。圧縮ファイルは暗号化ではありません。クラウドストレージへ保存する場合は、プラットフォームのエンドツーエンド暗号化または暗号化アーカイブを使用し、共有権限を制限してください。
プレースホルダー値を使い、構造を理解できる最小限の設定を作成する
mixed-port: 7890
external-controller: 127.0.0.1:9090
secret: REDACTED
proxies:
- name: test-node
type: socks5
server: example.com
port: 1080
username: REDACTED
password: REDACTED
proxy-groups:
- name: Test
type: select
proxies: [test-node, DIRECT]
rules:
- DOMAIN,example.org,Test
- MATCH,DIRECTDNS の問題であれば、DNS、一つのテスト用ポリシーグループ、関連するルールだけを残します。YAML の解析エラーであれば、エラー行前後の階層を残します。プレースホルダーへ置き換えた後、ローカルで同じエラーを引き続き再現できることを確認してください。再現できなければ、他人が見る内容は元の問題と異なります。
送信前にテキスト検索を行い、人の目でもう一度確認する
rg -n -i 'token|secret|password|passwd|uuid|private-key|authorization|cookie' .
git diff --staged
git log --all -- path/to/config.yaml検索で確認できるのは一般的なフィールドだけで、カスタム header、QR コード、名前を変更した認証情報までは識別できません。検索結果を確認した後も、共有するファイルを一行ずつ読み、ターミナルのプロンプト、ブラウザのタブ、スクリーンショット内の通知を確認してください。
実際の設定をすでに送信した場合は、マスキングを続けるのではなく認証情報を変更する
元のファイルをグループチャット、サポートチケット、公開リポジトリへすでに送った場合、機密情報を除去した版を追加で送っても、今後の誤用を減らすことしかできず、以前の認証情報は無効になりません。次に行うべきことは、すでに漏洩したファイルの編集を続けることではなく、認証情報のローテーションです。
| 漏洩した内容 | 直ちに行う対処 |
|---|---|
| 完全なサブスクリプション URL | サービスの管理画面で token/サブスクリプションアドレスをリセットし、各デバイスを更新する |
| external-controller secret | 新しい secret を生成し、制御ポートが信頼できないネットワークへ公開されていないことを確認する |
| ノードの認証情報 | サーバー管理者に、パスワード、UUID、PSK、秘密鍵を変更してもらう |
| Git の履歴 | 履歴を書き換えてすべての認証情報をローテーションする。最新のファイルを削除するだけでは不十分 |
| 公開されたログまたはスクリーンショット | 拡散を抑えるために取り下げ、同時に、公開された実際の認証情報を一項目ずつローテーションする |
変更後は、未ログインのウィンドウから以前のサブスクリプションアドレスへアクセスするか、以前の secret で制御インターフェースへリクエストし、実際に無効になったことを確認してください。クライアント上の表示名を変更したことや、公開投稿を削除したことでは、この検証を代替できません。
添付ファイル送信前の最終確認
トラブルシューティング用の添付ファイルが小さいほど、他人が理解しやすく、認証情報を見落とす可能性も低くなります。送信前に最後まで読み、このファイルが現在の問題だけを説明するものであることを確認してください。
送信できる条件
- 最小限のコピーでも、ローカルで同じエラーを再現できる
- すべての URL クエリパラメーター、ノード認証、secret を置き換えている
- ログに Authorization、Cookie、ローカルのユーザー名、絶対パスがない
- スクリーンショットに QR コード、アカウント、通知、無関係なタブがない
- 元の完全なバックアップを公開リポジトリや共有リンクへ送ったことがない