Clash Meta(Mihomo) tcp-concurrent 설정: DNS 멀티 IP 동시 연결과 호환성 (2026)

tcp-concurrent가 실제로 하는 일

Meta 계열 코어의 전역 설정 tcp-concurrent를 true로 두면, 어떤 목적지 호스트에 연결할 때 DNS 이름 해석 결과로 나온 모든 IP에 대해 동시에 TCP 연결 시도를 합니다. 그중 가장 먼저 성공한 연결을 채택하고 나머지 시도는 정리합니다. 공식 위키의 표현을 빌리면 “DNS가 반환한 모든 IP로 연결하고 첫 번째 성공을 사용한다”는 구조입니다. 그래서 CDN이나 글로벌 서비스처럼 하나의 이름 뒤에 레코드가 여러 개 붙는 환경에서는, 순차적으로 하나씩 물어보던 방식보다 첫 패킷이 나가기까지 걸리는 시간을 줄이는 데 도움이 되는 경우가 많습니다.

반대로 이름 해석이 단일 IP 하나만 돌려주면 동시 다이얼의 이점은 거의 없습니다. 이때 체감은 다른 요인—예를 들어 노드 RTT, 혼잡, TLS 재개, 로컬 방화벽—에 더 크게 좌우됩니다. 또한 이 옵션은 인바운드 트래픽을 여러 소켓으로 나누는 멀티플렉싱과도 다릅니다. 용어가 비슷해서 헷갈리기 쉬우니, “목적지별 IP 후보를 동시에 두드려 본다”는 한 줄로 기억하면 이후 설정 판단이 수월합니다.

1어디에 쓰나: 프로필 최상위

tcp-concurrent는 개별 프록시 항목이 아니라 설정 YAML의 루트에 두는 전역 스위치입니다. 일반적인 형태는 다음과 같습니다.

# Global profile (root level)
mode: rule

tcp-concurrent: true

proxies:
  # ...

Clash Verge Rev·Mihomo Party 등 GUI를 쓰는 경우에도 결국 동일한 키가 합쳐진 최종 프로필에 실려야 합니다. 클라이언트가 Mixin이나 패치 YAML을 제공하면, 거기 최상위에 tcp-concurrent를 넣어 베이스 구성을 덮어쓰는 패턴이 흔합니다. 여러 파일이 병합될 때는 나중에 적용되는 레이어가 우선이라는 점만 기억하고, 저장 후 실제로 로드된 설정에 키가 남아 있는지 확인하세요.

2켜고 끄는 절차

1. 백업: 수정 전 현재 프로필 전체를 복사해 두면 증상 비교가 빠릅니다.
2. 값 설정: 루트에 tcp-concurrent: true(켜기) 또는 false(끄기)를 추가·변경합니다.
3. 재로드: 클라이언트에서 프로필 적용·코어 재시작을 실행합니다. 일부 앱은 편집만으로는 메모리 상 옵션이 갱신되지 않을 수 있습니다.
4. 검증: 문제가 되던 대표 사이트나 API 몇 곳을 고정해 두고, 동일 시간대에 왕복 시간과 실패율을 비교합니다.

디버깅 중에는 로그 레벨을 잠시 높여 연결 시도가 어떻게 찍히는지 보는 방법도 있습니다. 대시보드를 쓴다면 외부 컨트롤러·Yacd 가이드를 참고해 연결 목록을 브라우저에서 훑을 수 있습니다.

첫 연결 지연과 기대치

동시 다이얼은 “느린 첫 번째 IP를 그대로 기다리는 대신, 빠른 IP가 나오면 그쪽으로 붙는다”는 식으로 이득이 납니다. 특히 해석 결과에 지역별·회선별로 품질이 들쭉날쭉한 주소가 섞여 있을 때 체감이 좋아지는 사례가 있습니다. 다만 추가적인 SYN 패킷이 나가므로, 극단적으로 협소한 업링크나 매우 엄격한 세션 모니터링 환경에서는 오히려 잡음으로 보일 수도 있습니다.

이미 노드 자체가 불안정하거나 DNS가 엉켜 있다면 tcp-concurrent만으로는 한계가 분명합니다. DNS 경로를 같이 손보고 싶다면 Meta 코어 DNS 유출 방지 가이드와 IPv6·듀얼 스택 트러블슈팅을 순서대로 점검하는 것을 권합니다.

호환성과 주의할 망

대부분의 가정용·일반 사무용 회선에서는 문제 없이 동작하는 편입니다. 다만 다음 상황에서는 false로 두고 A·B 테스트해 보는 것이 좋습니다.

• 기업 프록시·SSL 검사: 동시 연결 시도가 세션 로그에 비정상 패턴으로 찍히거나 정책과 충돌한다고 안내받은 경우.
• 극히 보수적인 방화벽: 짧은 시간에 동일 목적지 여러 IP로의 반복 연결이 차단 규칙에 걸리는 경우.
• 원인 분리: 연결 실패의 원인을 좁힐 때, 변수 하나로 tcp-concurrent만 꺼 보는 것이 디버깅에 유리합니다.

unified-delay·keep-alive와 헷갈리지 않기

unified-delay는 노드 지연을 표시할 때 연결 방식 차이를 보정해 숫자를 비교하기 쉽게 만드는 옵션입니다. tcp-concurrent와 목적이 다르므로, 지연 숫자가 바뀐 것처럼 보여도 서로 직접 대체 관계는 아닙니다. keep-alive-interval 같은 값은 링크 유지와 관련된 또 다른 축입니다. 튜닝할 때는 한 번에 하나의 전역 스위치만 바꾸고 결과를 기록하면 원인 추적이 훨씬 쉬워집니다.

자주 묻는 질문

프록시 그룹의 여러 노드를 동시에 쓰게 해 주나요?

아니요. 이 옵션은 DNS 결과 IP 후보에 대한 동시 연결을 다룹니다. URL-TEST나 FALLBACK 그룹에서 어떤 노드를 고를지와는 다른 레이어입니다. 노드 헬스 체크·자동 선택 동작은 기존 그룹 타입 문서를 따릅니다.

모바일·라우터에서도 동일한가요?

코어가 Meta 계열이고 동일한 전역 키를 지원하면 동작 원리는 같습니다. 다만 라우터나 저전력 장치는 동시 소켓 수·메모리 여유가 작아 체감이 PC와 다를 수 있습니다. OpenWrt·커널 튜닝을 병행한다면 OpenClash·분할 라우팅 글과 함께 부하를 보는 편이 안전합니다.

정리

Clash Meta·Mihomo의 tcp-concurrent는 한 줄로 켜고 끌 수 있지만, 의미는 “DNS가 알려준 모든 IP로 동시에 TCP를 열어 가장 빨리 붙는 곳을 고른다”입니다. 멀티 레코드 환경에서는 첫 연결 시간을 줄이는 데 도움이 될 수 있고, 반대로 폐쇄망·보안 정책·디버깅 상황에서는 끄는 편이 나을 수 있습니다. DNS·IPv6·노드 품질과 함께 조합해 판단하면 설정 실패 없이 목표에 더 빨리 도달합니다.

비슷한 전역 스위치만 따로 정리한 글로는 이번 주제가 해당하고, 앱별 분류 같은 다른 축은 PROCESS-NAME 튜토리얼에서 다룹니다. 문서 허브인 설정 가이드와 블로그를 함께 보면 프로필 전체를 한 번에 점검하기 좋습니다.

많은 범용 클라이언트는 프로필 편집·재시작 과정이 번거롭고, 옵션 의미를 사용자에게 설명하지 않은 채 숨겨 두기도 합니다. Clash는 시각적으로 프로필을 다루고 Meta 계열 기능과도 잘 맞추도록 설계되어 있어, 전역 TCP 튜닝을 포함해 일상적인 수정이 부담 없습니다. 아직 쓰지 않았다면 공식 다운로드 허브에서 클라이언트를 받아 tcp-concurrent를 적용해 보세요.