Clash·Mihomo relay 프록시 체인·다중 홉 YAML·dial 점검

0. 함께 열어 둘 문서(교차점)

이 글은 relay·다중 홉만 다룹니다. 노드 목록이 비었는지·구독이 비었는지는 구독·Provider 글에서, TLS·SNI만 이상한지는 TLS Handshake Timeout에서 먼저 가릅니다. url-test로 자동으로 출구를 바꾸는 패턴은 url-test·interval 글을 참고하세요. 체인은 이미 정의된 개별 proxies를 쌓는 것이지, “구독 한 줄”을 곧장 relay에 넣는 것과는 다릅니다.

1. 이런 요구에 relay(프록시 체인)가 붙습니다

“특정 국가의 중계(정거장)로만 먼저 올리고, 그 뒤에야 다른 리전 최종 프록시로 나가고 싶다”처럼, 한 번에 하나의 IP로는 표현할 수 없는 경로를 쓰고 싶을 때가 전형입니다. 이중·삼중 다중 홉은 지연이 늘고 한 홉만 쓰러져도 전체가 실패하므로, “체감 속도”가 아니라 경로 강제를 위해 쓰는지 스스로 확인하는 것이 좋습니다. Clash·Mihomo는 이런 조합을 type: relay로 묶고, proxy chains·릴레이라고 부르는 문서·로그가 많아 검색 키워드로도 잘 맞습니다.

2. YAML에서 relay 한 블록 만들기

proxies 배열에 합성 프록시를 하나 추가합니다. 핵심은 type: relay와, 이미 정의한 다른 프록시 이름을 proxies 리스트에 앞에서 뒤로 쌓는 것입니다. (코어·버전에 따라 별칭 키가 조금 다를 수 있으니 사용 중인 Clash·Mihomo 문서와 맞춰 보세요.)

아래는 이해를 돕는 가짜 이름 예시입니다. 실제 구독에서 내려온 name과 띄어쓰기·따옴표까지 맞아야 합니다.

# Example only — use real proxy `name` values from your config
proxies:
  - name: "HOP-A-SG"
    type: ss
    # ... (omitted) ...

  - name: "EXIT-US"
    type: vmess
    # ... (omitted) ...

  - name: "VIA-SG-TO-US"
    type: relay
    proxies:
      - "HOP-A-SG"
      - "EXIT-US"

이렇게 하면 VIA-SG-TO-US라는 한 개의 프록시가 생기고, 뒤에서 설명하듯 proxy-groups·규칙의 {"..."} 자리에 그 이름을 넣을 수 있습니다. 프록시 체인을 더 길게 쌓을 때도 proxies 리스트만 늘리면 됩니다. 다만 홉이 늘수록 실패 지점이 늘고, TLS·지연 원인을 한 홉에서 잡기 어려워질 수 있으니, “꼭 필요한 최소 홉”을 권장합니다.

주의: relay 안에 또 다른 relay를 끼워 넣는 식의 깊은 중첩·순환 참조는 구성·디버깅이 매우 어려워집니다. 팀·템플릿에서 한 단계씩 검증한 뒤에만 확장하세요.

3. 이름·순서가 틀리면 코어는 바로 멈춥니다

가장 흔한 실수는 (1) proxies 리스트에 아직 정의되지 않은 문자열을 넣는 것, (2) 구독이 갱신되며 name이 바뀌었는데 relay만 옛날 이름을 쓰는 것, (3) 따옴표·공백 오타입니다. 빈 노드·Provider가 아니라도, GUI가 보여 주는 별칭과 YAML의 name이 다르면 링크가 끊깁니다. 순서는 “먼저 연결될 첫 홉 → 그 다음 두 번째 …”이며, 기대한 지리적 경로와 정반대로 쓰면 “체인은 살아 있는데 사이트만 이상”한 착시가 날 수 있으니, 한 홉씩 개별 프록시만 켜서 나가는지 먼저 확인하는 편이 안전합니다.

4. proxy-groups·use에서 쓰는 법

proxy-groups의 proxies 목록에 relay로 만든 이름을 그대로 넣습니다. select이면 수동, url-test·fallback이면 “그룹이 고른 최종 후보”가 relay일 수도 있습니다. 중요한 점은, use로 구독 묶음을 쓰는 그룹과, relay 자체를 쓰는 그룹의 역할이 다르다는 것입니다. relay는 “한 번에 여러 hop을 묶은 단일 아웃바운드”이고, 측정·전환·세션은 그 한 덩어리에 함께 탑니다. 그래서 url-test로 “홉마다” 빠른 것을 고르는 식이 아니라, 전체 체인이 하나의 RTT·실패 단위로 취급됩니다. 자동 측정이 체감과 어긋나면 interval·tolerance뿐 아니라, 체인이 과하지 않은지도 함께 보는 것이 좋습니다.

5. 트래픽이 흐르는 머릿속 그림

로컬 애플리케이션 → (모드·규칙에 따라) Clash → relay에 적힌 첫 번째 항목으로 TCP/UDP를 붙이고, 그다음 두 번째로, … 순서대로 프록시 체인을 밟고 나갑니다. 그래서 첫 홉이 막혀 있으면 뒤 최종 출구는 아무 의미가 없고, “마지막만 바꾸면 해결”이 되는 문제가 아닌 경우가 많습니다. TUN·시스템 프록시를 켠 상태에서 쌍방 NAT·헤어핀 때문에 체감이 이상해질 수도 있으니, TUN·라우팅 글의 흐름과 겹치는지 점검하세요. 한 줄 요약: relay는 경로이지 “대역폭이 자동 합쳐지는” 기능이 아닙니다.

6. 로그에서 흔한 dial·체인 메시지 읽기

코어 로그에 dial·connect·chain·proxy·failed 류가 뜨면, 먼저 어느 홉에서 끊겼는지를 찾는 것이 우선입니다. 시간 초과면 해당 노드·포트·도메인이 실제로 막혔는지, refused면 앞홉 뒤의 리슨이 없는지, 인증 오류면 SS·Trojan 등 자격이 그 홉에 맞는지 봅니다. “체인”이라는 말이 나올 때는 relay가 여러 hop을 시도하다가 중간에서 실패한 경우가 많으니, 같은 로그에 찍힌 이름이 YAML의 proxies·구독과 짝이 맞는지 다시 읽으세요. TLS만 터지면 SNI·인증서 쪽을, fake-ip와 섞이면 DNS 쪽을 먼저 점검하는 편이 수월합니다. 한 번에 여러 키워드를 복사해 검색하기보다, 한 홉씩 단일 프록시로 떼어 테스트한 뒤에만 relay를 켜면 원인이 빨리 좁혀집니다.

7. UDP·프로토콜: 체인은 TCP 위주에 강하다

일부 게임·음성·실시간 트래픽은 UDP에 의지합니다. 개별 proxies 항목이 UDP를 끌어올리지 못하면, relay로 쌓아도 체인 전체가 실패하거나, 앱이 TCP로 폴백해 체감이 달라질 수 있습니다. Discord·Steam 등은 Windows·UDP·Steam 글에서 따로 정리한 것처럼, 프로세스·프로토콜 축이 큽니다. “relay만 붙이면 끝”이 아니라, 각 홉이 UDP를 지원하는지·클라이언트가 TUN/시스템 모드로 UDP를 코어에 넣는지까지 같이 봐야 합니다. 체감이 이상할 때는 억지로 홉을 늘리지 말고, 단일 저지연 노드·select로 고정하는 쪽이 나은 경우가 많습니다.

8. Mihomo·Clash Meta에서 API·로그·재시작

Mihomo를 쓰면 relay와 정책 그룹·규칙이 동일한 모델로 API에 노출됩니다. external-controller·secret이 막혀 있으면, GUI가 아무리 relay를 띄워도 실제 적용 여부를 확인하기 어렵습니다. Linux·서버는 Ubuntu·systemd로 journal에 붙이고, Windows는 클라이언트 로그에서 reload·error 키워드를 잡는 편이 좋습니다. YAML을 손댄 뒤에는 한 번에 키 여러 곳이 바뀌기 쉬우니, relay 블록을 추가했다면 name·use·rules에 같은 문자열이 도는지 검색해 보는 습관이 도움이 됩니다. 공식 문서의 “프록시·그룹” 흐름과 병행하면, “왜 이 규칙이 이 그룹을 탔는지” 시뮬레이션하기 쉬워집니다.

9. 점검 표: 위에서 아래로

proxies에 relay 이전에 쓰인 모든 name이 실제로 존재하는가
relay의 proxies 리스트 순서가 의도한 경로와 같은가(앞=첫 다이얼, 뒤=다음)
proxy-groups·rules·GUI에서 같은 문자열로 참조하는가(구독 갱신 후 별칭 충돌 없음)
로그에 dial·chain이 찍힌다면 어느 홉 키워드 뒤에 failure가 이어지는가
UDP가 필요한 앱이면 각 홉·TUN·앱이 프록시를 타는지까지

위를 통과해도 끊기면, relay를 잠시 끄고 맨 끝 출구만 단독으로 켠 뒤 vs 체인을 비교하세요. 한 홉씩 relay에 추가할수록, 실패는 곱절·지연은 합이 됩니다. 정책·규칙 전체는 문서의 “모드·DNS·규칙 순서” 절을 한 번씩 훑고 나서 다시 봅니다.

10. 맺음말

Clash·Mihomo의 relay는 YAML에 프록시 체인을 선언해 다중 홉·proxy chains을 만드는 직접적인 방법입니다. proxy-groups에 걸기 전에 proxies 이름·순서·dial 오류를 한 번에 잡는 습관이 있으면, url-test·API·Web 패널과 붙인 운영도 흔들리지 않습니다. “체감이 느리다”만으로 홉을 늘리지 말고, 필수 경로일 때만 relay를 쓰는 것이 Clash 설정을 오래 쓰는 비결이기도 합니다.

다른 프록시 툴 대비, 동일한 YAML·정책 그룹 모델로 데스크톱·서버·모바일을 맞출 수 있어, 릴레이를 한 번 정리해 두면 팀·가정 내 템플릿 공유에도 잘 섞입니다. 바이너리는 출처·업데이트를 통일해 두는 편이 안전하며, 공식 다운로드로 클라이언트를 맞춰 두면 GUI와 코어가 엇갈리며 생기는 “보이는 이름” 혼란도 줄어듭니다. 오픈소스 코드·이슈 추적은 저장소에서 확인할 수 있으나, 설치 파일은 이 사이트의 다운로드 흐름을 쓰는 것이 일관됩니다.

→ Clash를 무료로 내려받아 relay·프록시 체인을 직접 맞춰 보세요