「connection reset」はログ上で何を意味するか
OS やブラウザが出す接続リセットは、通信のどこかで TCP が RST 相当の形で打ち切られたことをユーザー側に知らせる表現に近いです。Mihomo のログに reset や connection reset、英語併記なら read tcp・write tcp 付近の失敗、といった行が出る場合、それは大まかに「コアが把握している出口まで進んだあと、上流または先方で接続が切られた」のか、「ローカルでプロキシが張る前に解決・ルール判定の段階で破綻した」のか、を切り分ける材料になります。ここを感覚ではなく、同じ数秒窓のなかの他の行（DNS、ルール、選択された proxy 名）とセットで見るのが最初の一歩です。
誤解しがちなのは、「reset が出る＝必ず遠隔ノードが悪い」という図式です。実際には、意図せず DIRECT に落ちた結果、キャリアや境界装置が RST を返しているケースも、ドメインが誤解決され、そもそも到達先が違うケースもあります。次の手順は、命中ルールと実際の出口名を先に一つに固定し、その上で上流を疑う順番を守ると迷いにくいです。ルール配列の先頭一致の整理は、ルール順と MATCH の稿とセットで押さえてください。
ステップ0：時刻を揃えて再現手順にタイムラインを引く
手元端末、仮想マシン、リモートデスクトップの時刻とタイムゾーンがずれていると、ログ上の time とブラウザの表示時刻が数時間ずれ、原因調査が空振りします。OS の設定を合わせたうえで、障害の再現操作を一度だけ行い、その直前直後 30 秒分のログだけを抜き出す習慣にすると、長大なログのなかを探し回る負担が大きく減ります。可能ならクライアントの接続パネルと同一時刻帯の項目（宛先、プロセス、ポリシー名）を画面キャプチャしておき、のちに rules 側の行番号や Rule Provider 展開と突き合わせやすくします。
ステップ1：一つのフローに対し「宛先 FQDN → ルール → 出口」を読む
多くの GUI は、フローごとに最終的に選ばれたポリシーと実際に使ったプロキシ名を並べます。まずはそこをメモし、debug 相当の冗長度でログに rule や Match、あるいはルール行の要約が出るかを確認します。Clash 系のルールは上から最初の一致で確定なので、画面に出た「命中行」が、YAML 上で自分が思っている行かどうかを ルール順の理解と照合します。ここで GEOIP,CN,DIRECT や巨大な RULE-SET より上に、目的の DOMAIN 行が来ているか、といった積み方の問題が一気に顕在化します。
コツ：HTTPS が IP 表示のままだとドメイン系ルールに乗りません。メタデータにホスト名が乗るよう Sniffer や解決まわりを揃えない限り、ログ上の「ルール上の出口」と体感がズレたまま reset 調査に入りがちです。
分岐A：プロキシ経路で落ちるとき（ノードとプロトコル）
ログ上、そのフローが明確に特定の proxy 名や url-test グループに載っている場合、次に疑うのは上流出力の体調です。帯域枯渇、プロバイダ側の接続数制限、特定ポートの制限、あるいは中継先の一時不調を切り分けるには、同じ出口で別の軽い宛先（小さな 204 応答を返す既知の URI 等）に切り替えて挙動が変わるか、を短時間だけ試し、url-test ／ fallback による別ノードへの自動退避が有効かを見るのが定石です。常に同じノードだけで reset が連打されるなら、購読の別ラインや遅延測定のしきい値を見直す価値があります。
UDP を伴う通話系アプリは、プロキシが UDP を十分に扱っていない・ルールが TCP 用の想定といった食い違いでも、別の形で断線に見えます。当サイトでは Discord 等を UDP と TUN の観点から切り分けています。純粋に HTTP(S) だけのサイトで reset が出るなら、まずはこの分岐 A と次の B のどちらに寄るかを優先して判断します。
分岐B：DIRECT か DNS のせいに見えるとき
フローが DIRECT に落ちているのに、望む宛先に届かない。あるいは、ブラウザのエラー表示時刻付近のログに意図した FQDN が出てこない。このときは、ルールより先に DNS モードと解決経路を疑います。FakeIP 利用時、解決名と分類用メタデータの名前一貫性が崩れていると、正しい DOMAIN 行に乗る前に別経路に滑ります。概要から設定の整合までは Meta 系 DNS 防リーク の稿で整理しているので、redial や fake-ip 周りの記述を一度見直し、「名前が二重に解かれていないか」を確認します。
fake-ip-filter で直結に戻すドメインが多すぎると、意図せず DIRECT 側の経路品質の影響を強く受けます。家計のルーターや社内回線のフィルタが RST 相当の挙動を返すと、プロキシ以前の実ネットパスがボトルネックだと分かるので、ログの policy: DIRECT 付近とセットで考えてください。
分岐C：ルールの「当たり先」は合っているがまだ不整合があるとき
ルール上は海外出口のはずが、購読更新で proxy-groups 内の参照名が壊れ、別の疎通不良ノードに沈んでいる。あるいは、REJECT 行が思ったより上に来ていて、表示上は「接続失敗」に近い。こうした場合は、YAML 全体の rules: より上ではなく、最終的に指している proxy-groups 配下を疑います。購読の失敗系は 購読更新 403 ／ タイムアウト の手順で切り分け、名前の不整合を取り除いてから、改めて接続ログの reset を追うと手戻りが減ります。
直し所の早見：ログで見えた事実から「触る場所」へ
次の表は、ログと画面で得られた事実から主に手を入れる層を指し示すための早見です。厳密な用語はビルドやクライアント表記差があるため、最終的には利用中の Mihomo バージョンの説明に合わせてください。
- 同一フローが常に同じ遠隔ノード名で
reset： 出口の替え・url-test／fallback・別プロトコル（遅延やブロック要因の切り分け）。 - 命中行は正しいのに、解決名と宛先表示が食い違う： DNS モード、FakeIP、
nameserverの二重解決、必要なら Sniffer。 - 望む
DOMAIN行に届く前に下の国別・集合ルールに飲まれる： GEOIP／GEOSITE より上への例外移動、Rule Provider の挿入位置の見直し。 - LAN や社内名だけ不調、それ以外は安定：
fake-ip-filterとスプリット DNS、直結名の扱い。
短いチェックリスト
- 端末の時刻とクライアントの時刻帯表記を合わせ、再現直後のログだけ抜き出す。
- 同じ数秒帯の行で、FQDN（または可視化された IP）／命中ルールの要約／出口名を一行ずつ揃えてメモる。
DIRECTかPROXY系かを先に分け、DIRECTなら DNS と国別帯、PROXYならノードと健康診断を先に疑う。- HTTPS が IP だらけのログなら、Sniffer または IP 系ルールでの暫定確認を挟み、メタデータにホスト名を戻す。
- ルールと出口を直したら、短時間だけ冗長ログを有効化して再現し、同じ手順を繰り返し可能にする。
注意： 長時間の debug 常時化は、ディスクとプライバシー双方に負荷がかかります。再現手順を決めたあと、必要最小限の時間帯に絞る運用にしてください。
クライアントの入手と情報源
コアの挙動やログ行の表記揺れは、メジャーバージョンで変わることがあります。GitHub 上のリリースノートで変更点を当たり、Issue で同種の reset 報告がないかを見るのは有効です。一方で、インストーラの第一入手経路としては、チーム内で 公式ダウンロードページ を共有しておくと、ビルドの取り違えが減ります。用語集めておきたい場合は、ドキュメント・チュートリアル も併用できます。
まとめ
Clash Meta／Mihomo のログに現れる connection reset 系の失敗を追うときは、時刻の一致、宛先 FQDN、命中ルール、実際の出口名を一つの事象に束ねてから、ノード・DNS・ルール順の三層のどれを触るかを決めるのが有効です。感覚的に「プロキシが弱い」と決めつける前に、DIRECT 誤配線と名前解決の食い違いを一巡させると、同じ reset 表記でも中身の違いに気づきやすくなります。長期的には、ルール配列の先頭一致を頭に置き、Sniffer や DNS を含めた可視化の一貫性を揃えておくのが、再発の手間を減らす近道です。
他ツールに比べ、テキストで経路を語れるのが Clash 系の長所なので、ログと YAML を往復しやすいクライアントを選び、一度きちんと揃ったプロファイルを再現性の高い形で保存しておくと安心です。接続品質の安定は、多くの場合「魔法の一発設定」ではなく、観測可能な層の積み上げです。