本稿で整理できること
tcp-concurrent が Mihomo／Clash Meta で扱う層、YAML における正しい置き場所、true にしたときに初動や再接続の体感が改善しやすい典型、逆にセキュリティ運用や切り分けの観点で false に戻す理由、unified-delay や prefer-ipv6 など名前が似るが別物のキーとの境界、最後に反映確認の短いチェックリストまでを一通り押さえます。購読テンプレをそのまま使っていて「一行だけ意味が分からない」状態から、意図を持ってオンオフできるようにすることが目的です。
tcp-concurrent が変える挙動
ざっくり言うと、同一の論理宛先に対して複数の IP（または経路）が候補として並んだとき、TCP の接続確立を待ち行列ではなく並行して試す方向に振るスイッチです。ドキュメントコメントにある対応表現では「複数 IP へ同時に TCP を張り、いち早く完了した握手を採用する」イメージに近いです。アプリケーションのダウンロード速度そのものやサブスクリプションの帯域を自動で押し上げるものではなく、最初の SYN／SYN-ACK のラウンドトリップが詰まりやすい環境で効きやすいことが多いです。
ここで言う「候補が複数ある」は、利用者の プロキシプロバイダのトポロジーというより、解決結果や中継チェーンの前後で複数のコネクション候補が並ぶ状況全般に心を当てると理解しやすいです。厳密な内部実装はバージョンで微差があり得るため、最終的には利用中リリースの公式ドキュメントと変更ログを正とし、本稿は運用者向けの地図として読んでください。
設定の場所と YAML スケッチ
典型的にはマージ後の実効プロファイルのトップレベルに次の一行を置きます。proxies や proxy-groups の内側ではなく、全体に効く一般設定のブロック近辺が無難です。GUI 付きクライアントでは「高度な設定」「一般」タブのトグルが内部で同じキーを書き換えていることもありますが、エクスポートしたテキストで最終形を確認するのが確実です。mixin／merge で上書きしている場合は、後勝ちの片方だけに残って見えなくなる事故が起きやすいので差分に注意してください。
# Sketch — merge into effective profile root; confirm with your Mihomo version
tcp-concurrent: true
# Optional neighbors often seen in templates (examples only; verify keys for your release)
# unified-delay: true
# ipv6: true
整理：false またはキー省略は「従来に近い逐次ダイヤル」寄り、true は「該当する状況で並行ダイヤルを許可」寄りと捉えると運用会議で説明しやすいです。
初包・体感レイテンシに効きやすい局面
CDN やマルチ A レコードまわり
外部のオリジンに対して名前解決が複数アドレスを返す場面では、逐次だと「遅い方の IP に当たってから次を試す」コストが乗りやすいです。並行化はその待ち時間を圧縮する方向に働きます。体感としてはページの最初の描画やAPI の最初の応答など、短い TCP 接続が繰り返されるワークロードで差が出やすい、という整理が現場では扱いやすいです。
失敗後の再試行が続くとき
一時的な経路不良やブラックホール的な宛先に当たると、逐次試行ではタイムアウトの積み上げがユーザー目線の「固まった」印象になります。並列化は万能ではありませんが、同タイミングで別候補に触れる確率を上げる方向です。根本原因が DNS の食い違いや誤ルールのときは、DNS／FakeIP 周りや ルール順のほうが支配的なので、そちらとの切り分けは必須です。
互換性と「オフ推奨」の現場
技術的には素直な最適化ですが、運用ポリシーとの相性でトラブルに見えることがあります。境界の IDS／IPS が、同一クライアントから短時間に複数の SYNが出るパターンを注意信号にしている例、ゼロトラスト製品のセッション相関が並行試行とぶつかる例、監査ログを一本のコネクト線として読みたいチームのニーズなどです。この手の環境では false に戻し、問題が消えるかを見るのがコスト対効果が高いです。
さらに淡々とした切り分け用途では、パケットキャプチャで想定外の並行フローが混ざると読み手が混乱します。インシデント対応中に一時的にオフにする、と決め打ちしてよいテーマです。逆に、家庭用回線や一般的な開発端末で、プロバイダが提示するテンプレのコメントに「速くなる可能性」とだけ書かれている行をそのまま活かすかどうかを判断する、という読み方も多いです。
注意：本稿の YAML はスキーマ例です。実リリースで廃止・改名されたキーがないか、必ず公式の一般設定ドキュメントと突き合わせてください。
よく隣接して現れるキーとの違い
unified-delay はヒットベースの遅延計測を揃えるためのスイッチであり、TCP ダイヤルの並列化そのものではありません。prefer-ipv6／IPv6 全般は名前解決やスタック選択の好みに関わり、まずどのアドレスファミリが候補に並ぶかを変えます。tcp-concurrent はその先の TCP レベルの並行試行に焦点を当てます。設定レビューで「遅延が気になるから全部オン」とまとめないで、文言どおりの責務に分解すると保守が楽になります。
TUN スタック（gvisor か system か）や UDP／QUIC の振る舞いは別次元です。TUN 記事 でレイヤを整理したうえで、TCP の話として tcp-concurrent を読むと誤解が減ります。
有効化・無効化の実務手順
- 実効 YAML をエクスポートし、いま
tcp-concurrentが存在するか、値が何かを確認する（未記載ならデフォルト解釈に従う）。 - ルートレベルに
trueまたはfalseを明示し、インデント崩れがないかを見る。 - 購読の再取得や mixin が起動のたびに上書きしないかを確認し、必要ならローカルの merge で固定する。
- 再読み込み後、文法エラーが出ていないかログの先頭を読む。
- 代表アプリで初回接続を数回試し、体感とダッシュボード上のタイムラインをオンオフで比較する。
反映確認のチェックリスト
- 起動ログに一般設定パースの失敗が出ていないか。
- GUI のバージョン表示が想定の Meta 系であるか（別フォークを読み込んでいないか）。
- 問題環境でオフにしたら境界アラートや認証プロキストの異常が止まるか。
- 体感差が出ない場合、ボトルネックがDNS・ルール・実ノードの RTTのどこかを疑う。
よくある質問（本文要約）
Q. すべてのクライアントメニューに出ますか。 表示名は実装差があります。Q. latency が悪化した。 稀に境界機器との組み合わせで逆効果に見えることがあり、false に戻して切り分けます。Q. セキュリティ上の推奨値は。 業界共通の絶対値はなく、組織のログ・IDS 方針に従ってください。
コンプライアンスの注意
職場・学校・契約ネットワークではプロキシの利用やトラフィックの暗号化が制限される場合があります。許可された範囲でのみ設定し、監査要件があるときは変更内容を改めて関係者に共有してください。
ドキュメントと入手
公式の用語整理は ドキュメント・チュートリアル、パッケージ入手は ダウンロードページ が安全です。コアの一般設定はリリースごとに細部が動くため、手元のバージョン番号をメモしたうえで読み直す習慣があると安心です。
まとめ
tcp-concurrent は Mihomo／Clash Meta において、TCP 接続確立を並行化して候補の中から早く届いた握手を優先しやすくするためのルート設定です。名前解決や遅延試験、TUN 形態とは別のレバーなので、レビューでは表を分けて説明するのがおすすめです。企業境界やインシデント対応ではオフに戻す判断も普通にあります。
オープンソースのコアは選択肢が多い一方、UI の有無やマージ戦略で「実際に効いている YAML」がブラウザ上の表示とずれることがあります。設定の一次ソースをテキストで握れるクライアントだと、本稿のような一行スイッチも含めて差分管理がしやすく、切り分けの往復が短くなります。手元の運用を単純化したい場合は、公式から Clash を入手し、エクスポートしたプロファイルに tcp-concurrent を明示して比較計測すると、自環境での効き具合が判断しやすくなります。