Clash Meta(Mihomo) relay 체인: 이중 홉 proxy-groups 작성법과 점검 순서 (2026)

왜 relay인가: 한 줄짜리 PROXY로 부족한 경우

실무에서 relay를 꺼내는 대표 이유는 세 가지로 묶을 수 있습니다. 첫째, 출구 IP를 특정 지역으로 고정해야 하는데, 중간에 다른 관할의 안정 노드를 거치고 싶을 때입니다. 둘째, 지역 잠금 해제나 서비스 정책상 “먼저 A 지역, 그다음 B 출구” 같은 경로가 필요할 때입니다. 셋째, 프라이버시 관점에서 단일 업스트림에 대한 직접 노출을 줄이고 싶을 때입니다. 이때도 법규·서비스 약관·소속 기관 정책을 반드시 지켜야 하며, 이 글은 기술 설정만 다룹니다.

relay는 proxy-groups에 type: relay를 주고 proxies 배열에 이미 정의된 노드 이름을 순서대로 나열하는 방식입니다. 코어는 일반적으로 클라이언트 쪽에서 가장 가까운 항목을 첫 홉, 그 다음을 두 번째 홉으로 연결합니다. 즉 목록의 앞쪽이 입구에 가깝고, 뒤쪽이 인터넷 쪽 출구에 가깝다고 이해하면 초기 설정이 수월합니다. (정확한 동작은 사용 중인 Mihomo 버전 문서를 한 번 더 확인하세요.)

1복붙용 스케치: proxies와 relay 그룹

아래는 개념을 잡기 위한 스케치입니다. proxies에 실제 구독에서 내려온 노드 이름 두 개가 있다고 가정하고, proxy-groups에 relay를 만듭니다.

# Sketch — merge into your real profile; proxy names must exist under proxies:
proxies:
  - name: "jp-entry"
    type: ss
    server: example.jp
    port: 8388
    cipher: aes-256-gcm
    password: "REPLACE_ME"
  - name: "us-exit"
    type: vmess
    server: example.us
    port: 443
    uuid: "REPLACE_ME"
    alterId: 0
    cipher: auto
    tls: true

proxy-groups:
  - name: "RELAY-JP-US"
    type: relay
    proxies:
      - jp-entry
      - us-exit

  - name: "PROXY"
    type: select
    proxies:
      - RELAY-JP-US
      - us-exit
      - DIRECT

핵심은 RELAY-JP-US처럼 relay 그룹 이름을 하나 두고, 그 안의 proxies에 체인에 쓸 노드 식별자만 순서대로 넣는 것입니다. 상위 select·url-test 등에서 이 이름을 고르면 트래픽이 체인으로 들어갑니다. 노드 이름 오타가 있으면 프로필 로드 단계에서 실패하거나 조용히 빈 그룹이 되므로, 저장 후 구성 오류 로그를 먼저 확인하세요.

2rules에서 relay 그룹에 붙이기

relay 자체는 “경로를 만드는 블록”이고, 실제로 트래픽이 그쪽으로 흐르려면 rules의 마지막이 MATCH로 어떤 정책 그룹을 가리키든, 중간 줄들이 RELAY-JP-US 같은 이름을 쓰도록 맞춰야 합니다. 흔한 패턴은 (1) 특정 DOMAIN-SUFFIX만 relay 그룹으로 보내고 (2) 나머지는 기존 PROXY·DIRECT로 두는 것입니다.

rules:
  - DOMAIN-SUFFIX,service.example.com,RELAY-JP-US
  - GEOIP,CN,DIRECT
  - MATCH,PROXY

여기서 실수하기 쉬운 점은 위쪽에 더 넓은 규칙이 먼저 매칭되어 relay 줄까지 도달하지 않는 경우입니다. Sniffer를 쓰지 않으면 HTTPS가 IP로만 보여 DOMAIN 규칙이 빗나가기도 합니다. 분류가 IP 위주로만 잡히면 GEOIP·RULE-SET과의 우선순위를 다시 그려야 합니다.

3DNS: relay가 “안 먹는 것처럼” 보이는 대표 원인

체인을 켰는데도 웹에서 보이는 출구나 DNS 응답 경로가 기대와 다르면, 문제가 relay가 아니라 DNS에 있는 경우가 많습니다. 예를 들어 OS·브라우저가 코어 밖의 DNS로 질의하면, 규칙과 무관하게 “누설”된 응답이 애플리케이션에 먼저 전달될 수 있습니다. FakeIP·DoH·TUN dns-hijack 조합은 DNS 유출 방지 글의 순서대로 맞추는 것이 안전합니다.

점검 순서 제안: (1) 문제 사이트에 접속을 시도한 직후 연결 로그에서 해당 행의 정책 이름이 relay 그룹인지 확인 (2) DNS 모드·업스트림이 프로필과 일치하는지 확인 (3) TUN을 쓰는 경우 TUN 가이드에 따라 캡처 경로가 빠지지 않았는지 확인. 세 가지 중 하나라도 어긋나면 “relay를 썼는데도 출구만 이상하다”는 증상이 납니다.

4규칙 순서와 스니퍼: DOMAIN이 relay까지 올까

rules는 위에서 아래로 평가됩니다. GEOIP나 광역 IP-CIDR이 먼저 걸리면, 아래에 아무리 정교한 DOMAIN-SUFFIX를 두어도 도달하지 않습니다. 반대로 과도하게 넓은 DOMAIN-KEYWORD를 relay 위에 두면 의도하지 않은 트래픽까지 체인으로 들어갑니다.

HTTPS에서 호스트가 보이지 않으면 Sniffer로 SNI를 복원한 뒤에야 DOMAIN 규칙이 의미가 있습니다. 정리하면, relay 문제로 착각하기 전에 “규칙이 실제로 내가 쓴 relay 이름을 선택했는가”를 로그 한 줄로 먼저 확인하세요.

5UDP·프로토콜: 이중 홉에서 자주 깨지는 부분

UDP를 쓰는 앱(일부 게임·음성·QUIC)은 노드와 프로토콜 조합에 따라 한 홉에서는 되는데 체인에서는 안 되는 경우가 있습니다. 중간 노드가 UDP를 제대로 전달하지 않거나, 출구 노드가 특정 프로토콜만 지원하는 식입니다. 증상이 “TCP 사이트만 되고 UDP 앱만 안 된다”면 relay 자체보다 프로토콜·UDP 지원을 의심합니다.

대응은 (1) 동일 앱을 단일 노드로만 보내 비교 (2) 클라이언트에서 UDP 관련 옵션·TUN·hijack 설정 재확인 (3) 필요 시 해당 트래픽만 relay가 아닌 다른 정책 그룹으로 분기하는 것입니다. 자세한 OS별 경로는 TUN 튜토리얼과 역할을 나눠 보세요.

6점검 순서(요약): 한 번에 한 변수씩

1. 프로필이 로드되는가: 문법 오류·노드 이름 불일치 없는지.
2. 규칙이 relay 그룹을 고르는가: 연결 로그·Yacd 등 패널에서 정책 이름 확인.
3. 각 홉 단독 연결: 첫 노드·둘째 노드를 각각 단일 PROXY로 테스트.
4. DNS 경로: FakeIP·하이재크·업스트림 일관성.
5. HTTPS DOMAIN 매칭: Sniffer·규칙 순서.
6. UDP·앱별 예외: 필요 시 PROCESS-NAME·별도 그룹.

위 순서를 지키면 원인 문장이 “relay YAML이 틀렸다”에서 “두 번째 홉 UDP만 실패한다”처럼 짧아집니다. 변수를 한꺼번에 여러 개 바꾸면 재현이 어려워지므로, 한 단계씩만 수정하는 것이 좋습니다.

한계·준수

• 체인 길이: 이론상 더 많은 홉을 넣을 수 있지만, 지연·실패 확률이 급증합니다.
• 상호 운용: 노드 프로토콜·암호 스위트가 맞지 않으면 체인 중간에서 끊깁니다.
• 정책: 회사·학교·국가 법규를 위반하는 우회 목적에는 사용할 수 없습니다.

정리

Clash Meta·Mihomo에서 relay는 proxy-groups에 이중 홉 이상의 경로를 선언하는 직관적인 방법입니다. proxies에 노드를 정의하고, relay 그룹의 proxies 배열에 순서대로 이름을 넣은 뒤, rules에서 그 그룹을 가리키면 됩니다. 다만 DNS·규칙 순서·HTTPS 도메인 가시성·UDP 중 하나만 어긋나도 체인이 “쓸모없어진 것처럼” 보이므로, 로그로 정책 적용 여부를 먼저 확인하는 습관이 중요합니다.

클라이언트 패키지는 릴리스 직링크보다 사이트 다운로드 허브에서 고르는 편이 플랫폼·빌드 혼선이 적습니다. 오픈소스 저장소는 이슈·라이선스 확인용으로 두고, 아래 링크에서 받은 뒤 relay 프로필을 바로 시험해 보세요.

→ Clash를 무료로 다운로드하고, Meta 코어로 relay 이중 홉을 프로필에 반영해 보세요