tcp-concurrent 在做什麼？
對照 Mihomo Wiki 對 TCP Concurrency 的描述：開啟後，核心會把由 DNS 解析得到的全部目的地 IP（含 IPv4／IPv6，視實際解析結果而定）拿來做並行出站嘗試，而非嚴格依序列逐一等候逾時再走下一個結果。對於 CDN、Anycast 或多線機房託管的代理域名，這意謂您能略過運氣較差的候選握手，把時間壓在第一個對您當下路徑友好的位址身上。它不會自動改寫規則，也不決定資料走哪個策略組；它只發生在已經決定要使用哪個出站、需要對該出站 server 網域名稱進行 Dial 的那一拍。
因此評估前要清楚邊界：若您的問題根因在於SNI／嗅探不匹配、規則順序過寬提前命中、或DNS 本身就回單一向量，開這個鍵對症狀的幫助可能極為有限甚至不可察覺。另方面，如果您的痛點是「代理域名每次解析都列出一長串機房位址，其中只有少數對您當 ISP 友善」，並行握手往往真能把首段 TCP 等價等待縮短，主觀體感接近「冷啟頁面或 API 首包更乾淨」。
小結：它是Dialer 對多維度解析結果的同時發起 TCP，不是對多個出站節點做負載分攤。
對首跳延遲、穩定性與日誌的實質影響
從協定角度，SYN 發出量是乘以解析紀錄筆數的短促尖峰；對一般桌面或筆電幾乎可忽略，但對蜂巢式按封包計費、或對上行連線數極度敏感的環境就可能顯得有感。成功連線會留下一條實際承載資料；未勝出的對象若端口關閉或路由黑洞，往往在日誌裡對應到RST／拒連類訊息。這並不一定代表設定錯誤，而是並行競速留下的正常副產物。若您對日誌清潔度非常敏感（例如自動監控告警對 connection refused 也會發Pager），可把 log-level 暫調或先關閉此功能做對照實驗。
「首包時間」並非總是正相關變短：在多個結果都很快的場景裡，額外延遲可能只是核心排程的微幅成本；在多個結果裡混入對您不可達但被解析回來的垃圾位址的情境，並行往往能顯著減省等待壞結果逾時的空轉時間。對齊出站 DNS 可信度因此依然重要——可複習 Meta DNS 指南 與 HTTPS 嗅探規則。
什麼情況建議開，什麼情況建議維持關？
傾向開啟的情境
- 節點域名由海外服務發布，常被解析成多個不同機房區塊，而其中一部分對您所在地的路由品質很差。
- 您已確認 DNS 對該出站網域回來的紀錄「大多可用」，只是時間上存在明顯的長尾握手。
- 您主要使用桌面客戶端或頻寬充裕的路由／小主機做代理閘道，短期 SYN 暴增不構成政策或成本控制問題。
傾向關閉或不要開的情境
- 企業或校園對同目的短時間多連線有可觀測的流量特徵門檻，容易被 NIDS 視為異常爆破。
- DIRECT（直連）規則對大量國內位址並行發起時，在日誌中出現
connection refused或類似紀錄，干擾排錯視線（公開討論區亦見組合環境的回報）。 - 硬體非常舊弱、並且同時有高併發長連線，您希望對核心負載採最小驚喜原則。
提醒：不要把它當「萬能治逾時」。若問題在 TLS 協定協商、出站憑證或策略組自動跳線節奏，請改看 健康檢查與自動容錯一文。
1以 YAML 設定與載入順序（所有圖形客戶端的共同底層）
無論您使用桌面 GUI 覆寫或純 YAML，核心是讀合併後的設定：tcp-concurrent 為根層級布林值，請與 mixed-port、mode、dns、tun 等區塊平級書寫。改完後請觸發客戶端提供的重載行為確保 Mihomo process 確實讀檔。
# Snippet — top-level tuning (merge carefully with your profile)
log-level: info
mode: rule
# Enable outbound TCP concurrency (first successful handshake wins among resolved IPs)
tcp-concurrent: true
# optional: orthogonal to tcp-concurrent; tweaks delay probes for proxy groups
# unified-delay: true
# proxies / proxy-groups / rules ...
關閉只要把鍵移除或設定為 false：tcp-concurrent: false。若您完全不寫這個鍵，行為將追隨所使用核心版本的預設；升級 Mihomo minor 後若感覺「連線質感突然變了」，第一步值得核對發行說明與這個鍵是否曾由訂閱範本帶入。使用 mixin 覆寫 時，請留意合併層級與遮蔽關係，避免以為改了外層、實際被底稿覆蓋。
2圖形客戶端的操作直覺
多數發行版不會在首頁放巨大按鈕寫這個英文名稱；實際路徑通常是進階組態／YAML 視窗／設定覆寫區塊。若介面語言將其譯為「並行 TCP」「TCP 並發」，語意對應即本文主題。對照完成後請仍用前述 YAML 確認拼字與層級。若您是 TUN／系統代理雙模使用者，並行並不取代 TUN——若應用不讀系統代理而未進核心，問題仍與 進程級規則 或 TUN 覆蓋有關，本文開關幫不上。
與 unified-delay、Dial 行為與 IPv6
unified-delay處理的是對節點做延遲測試時的算法差異消除，與對真實目的位址發起並行出站屬於不同的抽象層：前者影響您「看見的毫秒數」，後者影響您「對外資料管線何時建好」。若要同時啟用請各自理解副作用，並避免把測得的漂亮 ping 自動等同於複雜站點的完整頁載體驗。若環境為雙棧，解析回 IPv6／IPv4 混合時並行對兩種家族同時發力，對某些僅半截打通的過渡網際路由可能立竿見影——亦可能曝露對端對某一族政策的封鎖，需對照 IPv6 雙棧排查。
3觀察與回滾的建議順序
建議準備固定三連測試：同一瀏覽器冷啟兩個常卡首包的網址、再打一次對 API 終端發送的小請求工具。第一輪維持關閉紀錄主觀與毫秒級工具輸出，第二輪開啟重複同等條件，若結果雜訊變大而主觀無改善就立刻回復關閉。除錯期間可把 log-level 調到您能讀懂又不洪水的級別（通常 info 足夠觀察失敗對象數量）。
- 備份完整設定快照（含 mixin 順序備註）。
- 寫入
tcp-concurrent: true，重載核心。 - 重跑三連測試並截圖或記錄關鍵錯誤字串。
- 發現對 DIRECT 區段或國內目標日誌汙染，立即改回 false 並評估是否要收紧 DNS／規則邊界。
常見問題（對照前文速查）
問：tcp-concurrent 開啟後一定會更快嗎？
只有在出站主機經 DNS 綁定多個可連線 IP 且有部分位址握手較慢或失敗時，縮短輪詢順序的收益才明顯；若本就單一位址或上游只回一個 A 記錄，您多半感覺不到差異。
問：它與 unified-delay 有什麼不同？
unified-delay調整「測速演算法對不同協議的公平性」，tcp-concurrent調整「實際對外建立 TCP 的並發策略」——兩者可以並存，勿互相混淆職責。
問：日誌裡為何會對同一類目標看到很多 connection refused？
並行握手時對未勝出的對象發生拒連是常態；視為性能取捨的副產物即可。但若伴隨實際工作流失敗，請先關閉功能再分析 DNS／防火牆。
問：路由器上是否建議預設開？
不一定。資源吃緊或連線密度極高時，保守起見先關，改以節點品質與可信 DNS 為主。
開源資訊與安裝包取得方式
Mihomo 上游以開源形式維護，行為細節以版本為準；若您要核對某個小版本是否調整預設，宜直接閱讀對應 tag 的說明與變更紀錄。日常取得圖形客戶端安裝包仍建議走 本站 Clash 下載頁，並用 設定說明文件理解名詞，把「下載安裝」與「追蹤上游 issue」分開，避免誤以為必須自行拼裝二進位。
結語
tcp-concurrent 把「DNS 回給我的每個候選 IP」變成同場競速的 TCP 起點，在跨區代理、多線機房與路由長尾明顯的組合裡，常常比盲目更換訂閱或堆更多 DOMAIN 規則更貼近根因。但它也會帶來短暫封包尖峰與更吵的日誌，需要您用可重現的基準測試決定是否長期保留。把它與 DNS、策略組健康檢查、以及必要時的 TUN 覆蓋一起思考，才是完整的 Clash Meta 調校路徑。
相較之下，部分圖形工具把進階鍵藏得很深，又缺乏「改完如何驗收」的引導，使用者容易在開關之間搖擺卻沒有日誌閉環；Clash 生態把同一套 Mihomo 行為同時暴露給 YAML 與視覺化編輯，使得像 tcp-concurrent 這類代理 TCP 優化可以在理解成本可控的前提下被精準使用。若您尚未安裝客戶端，可以免費下載 Clash，先以本文節奏做一次開關對照，再把結論寫回您的長期設定模板。