MCP 원격 끊김? Clash 분류·MCP 호스트·저지연 노드

1. MCP와 「자꾸 끊기는」 증상

Model Context Protocol은 LLM이 에디터 안에서 외부 리소스·도구와 대화하기 위한 계층으로 이해하면 됩니다. 클라이언트는 로컬 프로세스일 수도 있고, 팀이 배포한 원격 MCP 서버에 HTTPS나 WebSocket Secure(WSS)로 붙는 구성도 흔합니다. 이때 연결은 짧은 API 호출 한 번으로 끝나지 않고, 세션·스트림·하트비트에 가까운 장시간 소켓으로 유지되는 경우가 많습니다.

그래서 일반 웹 서핑과 달리 (1) 왕복 지연이 조금만 커져도 타임아웃이 나기 쉽고, (2) 노드가 바뀌거나 경로가 흔들리면 스트림이 끊긴 뒤 재협상에 실패하는 식으로 보일 수 있습니다. 또한 IDE 확장이 붙는 호스트명이 구독 규칙 세트에 없으면, 의도와 다르게 DIRECT나 다른 지역 노드로 나가 반쯤만 성공하는 패턴도 나옵니다. 사용자 입장에서는 「MCP 연결 실패」「도구 응답 없음」 같은 메시지로 남습니다.

보안과 약관 측면에서 회사 데이터를 다루는 MCP는 반드시 내부 정책을 따르고, 본문은 네트워크 출구와 규칙 매칭만 다룹니다. 클라이언트 UI 차이는 Windows용 Clash 클라이언트 비교와 공식 문서를 함께 보면 설정 속도가 빨라집니다.

2. 범용 프록시에서 분리해야 하는 이유

많은 프로필이 「해외 사이트는 한 그룹」처럼 넓게 묶여 있습니다. 이렇게 해 두면 브라우저·패키지 매니저 트래픽은 대체로 돌아가지만, MCP 전용 호스트는 다음 이유로 따로 두는 편이 낫습니다.

지연 민감도: 채팅 API보다 도구 호출 체인이 길어 작은 지연도 누적됩니다. 멀리 떨어진 출구를 쓰면 체감이 큽니다.
연결 유지: url-test만으로 자동 전환되는 그룹에 넣어 두면, 측정 순간마다 다른 노드로 옮겨 가며 스트림이 끊길 수 있습니다.
규칙 순서: 상위에서 이미 다른 정책에 매칭되면 MCP용 줄은 실행되지 않습니다. 구체적인 호스트 규칙을 위쪽에 두는 패턴이 필요합니다.

팁: 「MCP 프록시」「MCP 연결 실패」로 검색해 온 경우, 먼저 Clash 연결 로그에서 실제로 어떤 호스트명이 찍히는지 확인하세요. 추측으로 도메인을 채우면 오탐이 늘어납니다.

3. 원격 호스트·포트·WSS 확인하기

배포 방식마다 호스트는 mcp.example.com 형태일 수도 있고, 클라우드 벤더의 임시 도메인일 수도 있습니다. IDE 설정 JSON·환경 변수·팀 위키에 적힌 엔드포인트 문자열을 기준으로 목록을 만드는 것이 가장 안전합니다.

실무에서 쓸 수 있는 방법

에디터·MCP 클라이언트의 로그·디버그 출력에서 연결 시도 URL을 그대로 복사합니다.
터미널에서 해당 프로세스가 붙는지 확인할 때는 OS별 네트워크 도구를 쓰되, 회사 보안 정책을 지킵니다.
WSS인지 일반 HTTPS인지에 따라 중간 프록시·방화벽에서 막히는지가 달라질 수 있으므로, 스킴까지 메모합니다.

로컬에서 localhost로만 돌아가는 MCP는 Clash 원격 분류 대상이 아닙니다. 반대로 팀 서버가 공인 DNS를 쓰면 그 호스트가 바로 규칙에 들어갑니다. 터미널·환경 변수 글과 같이 읽으면, IDE가 셸과 다른 출구를 쓰는지도 대조하기 쉽습니다.

4. 분류 규칙·프록시 그룹 예시

Clash(Mihomo 계열)에서는 RULE 모드에서 위에서 아래로 첫 매칭이 적용됩니다. MCP 관련 호스트를 MCP-LowLatency 같은 그룹으로 보내려면, 아래는 이해를 돕기 위한 스켈레톤이며 실제 운영 시점의 이름은 반드시 본인이 관측한 값으로 바꿉니다.

proxy-groups:
  - name: MCP-LowLatency
    type: select
    proxies:
      - 노드-A-저지연
      - 노드-B-백업
      - DIRECT

rules:
  - DOMAIN-SUFFIX,your-mcp.example.com,MCP-LowLatency
  - DOMAIN-KEYWORD,internal-mcp,MCP-LowLatency
  - MATCH,Others

DOMAIN-KEYWORD는 편하지만 오탐이 생기기 쉬워, 장기 운영에는 DOMAIN-SUFFIX와 로그로 검증된 호스트 위주가 안전합니다. 구독으로 받은 대형 규칙 세트 위에 개인 MCP 줄을 얹을 때는, 반드시 순서를 한 번은 직접 확인하세요. 상위에서 이미 다른 그룹으로 빠지면 아래 줄은 실행되지 않습니다.

proxy-groups의 use 항목으로 프로바이더 노드를 끌어오는 구성이라면, 그룹 이름이 YAML 전체에서 일관되게 참조되는지도 함께 봅니다. 오타 하나로 MCP-LowLatency가 존재하지 않는 상태로 저장되면, 클라이언트가 기동 시 경고를 내거나 예상과 다른 출구로 떨어질 수 있습니다.

5. 저지연 노드와 그룹 유형

프록시 그룹에서 url-test는 지연이 가장 낮은 노드를 고르지만, 측정 주기마다 전환이 일어날 수 있어 장시간 스트림에는 부담이 됩니다. MCP처럼 연결이 길게 유지되는 트래픽에는 select로 수동 고정하거나, 전환을 보수적으로 잡은 fallback을 실험해 보는 편이 낫습니다.

같은 구독 안에서도 서버 위치·회선 품질이 다르면 TLS 왕복과 패킷 손실이 달라집니다. 「핑이 가장 낮다」만으로 고르기보다, 실제 MCP 호스트에 대한 체감으로 노드를 정하고, 문제가 생기면 그 그룹만 바꿔 비교하는 방식이 디버깅에 유리합니다. TLS 단계에서 자주 막히면 TLS Handshake Timeout·SNI 글의 순서로 노드·SNI·규칙을 나눠 보세요.

주의: 신뢰할 수 없는 공개 노드는 트래픽이 노출될 수 있습니다. 토큰·내부 URL이 오가는 MCP라면 검증된 출구와 최신 클라이언트를 쓰는 것이 안전합니다.

6. DNS·TUN·시스템 프록시 정렬

규칙이 정확해도 DNS가 먼저 틀어지면 「프록시를 탔는데도 이상하다」는 상태가 됩니다. fake-ip 구성에서는 도메인별 매핑 타이밍이 민감하고, IDE가 시스템 리졸버와 다른 경로를 쓰면 매칭 결과가 흔들릴 수 있습니다. 점검할 때는 (1) Clash 클라이언트의 DNS 설정, (2) 운영체제 DNS, (3) 에디터·런타임의 별도 DoH 설정이 서로 싸우지 않는지 순서대로 봅니다.

TUN 모드는 프로세스 전체를 끌어올리기 쉬워 MCP 트래픽도 같은 스택을 타게 만들 수 있지만, 다른 VPN·보안 소프트웨어와 가상 어댑터 우선순위가 충돌하면 예외가 늘 수 있습니다. 시스템 프록시만 켠 구성에서는 반대로, 터미널이나 백그라운드 프로세스가 프록시를 타지 않아 Cursor·GitHub 글에서 다룬 것과 비슷한 「일부만 실패」가 나올 수 있습니다. 한 가지 모드만 고집하기보다, 증상에 맞춰 TUN·시스템 프록시·환경 변수를 한 축씩 바꿔 재현해 보는 편이 안전합니다.

7. Cursor·GitHub 타임아웃 글과의 관계

같은 IDE 주변 이슈라도 Cursor·GitHub 타임아웃 글은 Git 호스트·저장소·API에 맞춘 도메인 묶음과 타임아웃을 다룹니다. 본문은 그보다 MCP 전용 원격 호스트·장시간 연결에 초점을 둡니다. 두 글을 함께 적용할 때는 규칙이 서로 앞서 매칭되지 않는지, 그리고 DNS·TUN 설정이 한 프로필 안에서 일관적인지 확인하세요.

실무에서는 「GitHub는 안정적인데 MCP만 끊긴다」처럼 증상이 갈라지는 경우가 많습니다. 이때 GitHub용 그룹과 MCP용 그룹을 완전히 동일하게 맞출 필요는 없습니다. 서비스마다 최적 출구가 다를 수 있으므로, 호스트 관측 결과에 따라 용도별로 나누는 것이 장기적으로 안정적입니다.

8. 증상별 점검 표

아래 표는 증상별로 무엇을 먼저 볼지 정리한 것입니다.

증상	의심 지점	조치
도구 목록만 사라짐	장시간 연결 끊김·노드 전환	MCP용 `select` 고정, 스트림 호스트 규칙 추가
간헐적 타임아웃	DNS 흔들림·높은 지연 노드	DNS 정렬, 저지연 노드로 그룹 분리
다른 사이트는 빠른데 MCP만 느림	규칙 누락·오탐	로그에서 호스트 확인 후 `DOMAIN-SUFFIX` 추가
TLS 오류만 반복	SNI·인증서·중간 장비	TLS 글·노드 교체 순으로 좁히기

한 번에 여러 설정을 바꾸면 원인 추적이 어려워집니다. 변수를 하나씩 줄이고, 같은 MCP 작업을 재현 가능한 짧은 시나리오로 남겨 두면 이후에도 같은 팀과 공유하기 좋습니다.

9. 마무리

MCP로 붙는 원격 호스트는 범용 웹 트래픽과 섞어 두면 노드 전환·지연·DNS 불일치에 더 취약합니다. Clash 분류 규칙으로 MCP용 호스트를 앞쪽 규칙에 두고, 프록시 그룹에서 저지연 출구를 고정하면 장시간 연결이 끊기는 체감을 줄일 수 있습니다. 증상이 복합적일 때는 GitHub·API와 호스트 세트가 다른지부터 구분하는 습관이 중요합니다.

문서화된 클라이언트와 최신 코어를 쓰면 규칙 테스트와 연결 로그 확인이 쉬워, MCP처럼 호스트가 자주 바뀌는 환경에서도 프로필을 빠르게 고칠 수 있습니다. 기본 개념은 사이트 문서에서 확인한 뒤, 이 글의 순서대로 호스트 관측과 그룹 설계를 맞춰 보세요.

설치 패키지는 공식 다운로드 페이지에서 받는 것이 혼선이 적고, 오픈 소스 저장소는 빌드·이슈 확인용으로 참고하면 됩니다.

→ Clash를 무료로 내려받아 MCP용 분류 규칙과 노드 정책을 개발 환경에 맞게 조정해 보세요