Clash 초보자 FAQ 10가지: 구독 링크 가져오기, 규칙·전역 모드 선택, 포트 용도

1. Clash, 클라이언트, mihomo는 각각 무엇인가요?

‘Clash’는 보통 코어를 가리키기도 하고, 그래픽 인터페이스가 있는 클라이언트를 뜻하기도 합니다. 코어는 연결을 받아 규칙을 적용하고 프록시 서버에 연결하며, 클라이언트는 구독 관리, 화면 조작, 시스템 프록시 설정, 코어 프로세스 관리를 담당합니다. 문제를 진단할 때는 ‘Clash 최신 버전’이라고만 하지 말고 클라이언트 이름과 코어 이름을 모두 확인해 두세요.

Clash Meta는 Clash 생태계에서 발전한 포크로, 이후 mihomo라는 이름을 사용하게 됐습니다. 클라이언트마다 탑재된 코어가 다를 수 있어 지원하는 프로토콜, 규칙 필드, TUN 설정도 완전히 같지 않습니다. mihomo에서 불러올 수 있는 설정이라고 해서 구버전 Clash 코어가 모든 필드를 인식하는 것은 아닙니다.

클라이언트 버전: 보통 ‘정보’ 페이지에서 확인할 수 있으며, 메뉴 구성과 설정 관리 기능을 결정합니다.
코어 버전: 보통 ‘코어’ 또는 ‘정보’ 페이지에서 확인할 수 있으며, 설정 문법과 프로토콜 지원 여부를 결정합니다.
구독 서비스: 서버 정보나 설정을 제공하는 서비스입니다. 클라이언트와는 별개이며, 클라이언트를 설치한다고 자동으로 제공되는 것은 아닙니다.

더 알아보기: 클라이언트 다운로드에서 운영체제에 맞는 제품을 선택하고, 프로토콜 레퍼런스에서 코어의 지원 기능을 확인하세요.

2. 구독 링크는 어떻게 가져오며, 가져온 뒤 적용되지 않는 이유는 무엇인가요?

구독 링크는 설정이나 노드 정보를 가져오는 주소입니다. 전체 Clash YAML을 반환할 수도 있고 노드 목록만 반환할 수도 있습니다. 노드 목록만 있는 경우 완전한 설정으로 바로 실행할 수 없으므로, 서버에서 현재 사용하는 클라이언트나 코어에 맞는 구독 형식을 제공해야 합니다.

일반적인 가져오기 순서

구독 서비스 페이지에서 Clash 또는 mihomo용 구독 주소를 복사하세요. 계정 관리 웹페이지 주소와 혼동하지 않도록 주의하세요.
클라이언트의 ‘설정’ 또는 ‘Profiles’ 페이지를 열고 ‘추가’, ‘URL에서 가져오기’와 같은 메뉴를 찾으세요.
주소를 붙여 넣고 다운로드한 다음, 목록에 설정 이름이 표시되고 파싱 오류가 없는지 확인하세요.
설정을 선택하거나 활성화한 뒤 ‘프록시’ 페이지에서 프록시 그룹과 노드가 표시되는지 확인하세요.
사용할 수 있는 노드를 선택하고 필요에 따라 시스템 프록시를 켜세요. 설정을 가져오는 것만으로 앱 트래픽이 코어를 거치게 되는 것은 아닙니다.

메뉴 이름은 제품마다 다릅니다. 위 순서는 작업 흐름을 설명한 것이며, 모든 클라이언트에 공통으로 적용되는 고정 메뉴 경로는 아닙니다. HTTP 401 또는 403 오류가 표시되면 구독 권한과 만료일을 먼저 확인하세요. 다운로드는 됐지만 YAML 파싱 오류가 발생한다면 응답 내용이 로그인 페이지, 오류 메시지 또는 호환되지 않는 형식인지 확인하세요.

더 알아보기: 빠른 시작에 따라 가져오기와 활성화를 마치고, 다운로드에 실패하면 도움말 센터를 확인하세요.

3. 규칙, 전역, 직접 연결 모드는 어떻게 선택해야 하나요?

모드는 ‘코어에 들어온 연결을 어떤 출구로 보낼지’를 결정합니다. ‘어떤 앱의 연결을 코어로 보낼지’를 정하는 것은 아닙니다. 시스템 프록시나 TUN을 설정하지 않고 전역 모드만 켜면 모든 프로그램이 자동으로 클라이언트를 거치는 것은 아닙니다.

모드	처리 방식	적합한 상황
규칙 Rule	설정에 정의된 규칙 순서에 따라 정책을 적용합니다	직접 연결과 프록시 연결을 구분해야 하는 일상적인 사용
전역 Global	전역 정책 그룹에서 선택한 출구로 보냅니다	출구를 잠시 비교하거나 분기 규칙을 진단할 때
직접 연결 Direct	이 기기에서 대상에 직접 연결합니다	프록시 출구를 잠시 우회해 기본 네트워크를 비교할 때

규칙 모드는 일반적으로 위에서 아래로 확인해 처음 일치하는 규칙을 적용합니다. 아래는 규칙 일부일 뿐, 단독으로 가져올 수 있는 전체 설정이 아닙니다. ‘기본 출구’는 설정에 이미 존재하는 프록시 또는 프록시 그룹의 이름이어야 합니다.

rules:
  - DOMAIN-SUFFIX,example.com,DIRECT
  - MATCH,기본 출구

예시에서는 example.com과 하위 도메인을 직접 연결하고, 나머지 연결은 ‘기본 출구’로 보냅니다. 이 그룹에서 현재 DIRECT를 선택했다면 나머지 연결도 직접 연결됩니다. 따라서 ‘규칙 모드가 켜져 있다’고 해서 현재 요청이 반드시 프록시 서버를 거치는 것은 아닙니다.

더 알아보기: 프로토콜 레퍼런스에서 규칙 유형, 정책 이름, 매칭 순서를 확인하세요.

4. 노드와 프록시 그룹은 어떻게 다르며, 노드는 어떻게 바꾸나요?

노드는 일반적으로 특정 프록시 서버 하나를 가리키며, 프록시 그룹은 규칙에서 참조할 수 있는 선택 계층입니다. 그룹에는 노드나 다른 프록시 그룹뿐 아니라 DIRECT도 포함될 수 있습니다. 노드를 바꿀 때는 홈 화면에 표시된 노드 이름만 보지 말고 요청이 최종적으로 어떤 그룹에 매칭되는지 확인하세요.

select: 후보 중 하나를 직접 선택합니다. 출구를 고정해야 할 때 적합합니다.
url-test: 설정된 테스트 결과를 바탕으로 후보를 자동 선택합니다. 테스트 주소와 허용 오차 등 설정에 따라 결과가 달라집니다.
fallback: 후보 순서에 따라 상태 확인을 통과한 항목을 선택합니다. 지연 시간이 가장 짧은 항목만을 기준으로 선택하지는 않습니다.

먼저 ‘연결’ 페이지에서 대상 도메인에 해당하는 연결을 찾아 매칭된 규칙과 프록시 체인을 확인한 뒤, 해당 프록시 그룹으로 돌아가 노드를 바꾸세요. 변경 사항은 보통 새 연결부터 적용됩니다. 기존 다운로드, 동영상 재생, 장시간 연결은 이전 출구를 계속 사용할 수 있으므로 다시 연결한 뒤 확인하세요.

지연 시간이 80ms로 표시돼도 해당 테스트에 걸린 시간만 알 수 있을 뿐, 다운로드 속도를 계산할 수는 없습니다. 처리 속도는 대역폭, 혼잡도, 대상 사이트, 로컬 네트워크에도 영향을 받습니다. 지연 시간이 시간 초과로 표시되는 경우에도 테스트 주소에 접속할 수 없었을 수 있으므로 실제 요청 결과를 함께 확인하세요.

더 알아보기: 빠른 시작에 따라 프록시 그룹을 선택하고, 연결 문제는 도움말 센터의 진단 절차를 참고하세요.

5. 7890, 7891, 9090 포트는 각각 어떤 용도인가요?

이 숫자는 흔히 사용하는 예시일 뿐, 모든 클라이언트의 기본값은 아닙니다. 실제로 사용하기 전에 클라이언트의 포트 설정이나 현재 적용 중인 설정에서 값을 확인하세요. 특히 프록시 연결 포트와 관리 인터페이스 포트를 구분해야 합니다. 관리 포트를 브라우저 프록시 설정에 입력하면 안 됩니다.

mixed-port: 7890
allow-lan: false
external-controller: 127.0.0.1:9090

위 예시에서 7890은 HTTP와 SOCKS를 함께 지원하는 프록시 포트이고, 9090은 관리 인터페이스에서 사용하는 컨트롤 포트입니다. allow-lan: false는 LAN에 프록시 서비스를 제공하지 않을 때 설정합니다. 일부 구형 설정은 HTTP와 SOCKS 포트를 별도로 지정합니다. 예를 들어 port: 7890, socks-port: 7891처럼 설정하므로 숫자만 보고 프로토콜을 추측하지 마세요.

명령어로 프록시 포트 확인하기

curl --proxy http://127.0.0.1:7890 --connect-timeout 10 --head https://example.com

이 명령어는 로컬 7890 포트를 명시적으로 지정하고 연결 시간 제한을 10초로 설정합니다. Windows PowerShell에서는 구버전 환경에서 발생할 수 있는 명령 별칭 차이를 피하기 위해 curl.exe를 사용할 수 있습니다. 연결이 거부되면 코어 실행 여부와 포트 설정이 일치하는지 먼저 확인하세요. HTTP 응답이 왔다는 것은 요청에 응답이 있었다는 뜻이지, 모든 웹사이트에 접속할 수 있다는 의미는 아닙니다.

더 알아보기: 프로토콜 레퍼런스에서 수신 설정을 확인하고, 포트 충돌은 도움말 센터에서 해결하세요.

6. 시스템 프록시를 켰는데 브라우저나 터미널이 프록시를 사용하지 않는 이유는 무엇인가요?

시스템 프록시는 앱에서 가져다 쓸 수 있도록 제공되는 프록시 설정이지, 시스템 전체 트래픽을 강제로 전달하는 기능은 아닙니다. 대부분의 브라우저는 시스템 프록시를 사용할 수 있지만, 명령줄 도구나 게임, 자체 네트워크 스택을 구현한 앱은 이를 무시할 수 있습니다. 브라우저 프록시 확장 프로그램이 시스템 설정을 덮어쓸 수도 있습니다.

먼저 앞 절의 프록시 지정 명령어로 테스트해 ‘프록시 포트에 연결할 수 없는 문제’와 ‘앱이 프록시를 사용하지 않는 문제’를 구분하세요.
브라우저의 프록시 확장 프로그램, 별도 프록시 설정, 예외 목록을 확인하세요. 여러 도구가 동시에 프록시 설정을 변경하지 않도록 주의하세요.
클라이언트의 ‘연결’ 페이지에서 요청이 표시되는지 확인하세요. 기록이 없다면 노드를 계속 바꾸기보다 트래픽이 클라이언트로 들어오는 경로부터 점검하세요.
터미널 도구는 해당 도구의 문서에 따라 환경 변수나 프록시 옵션을 설정하세요. 더 많은 앱을 연결해야 한다면 TUN 모드를 검토하세요.

예를 들어 macOS 또는 Linux의 현재 셸에서는 다음과 같이 임시 설정할 수 있습니다.

export http_proxy=http://127.0.0.1:7890
export https_proxy=http://127.0.0.1:7890
curl --head https://example.com
unset http_proxy https_proxy

https_proxy 값에 http://를 사용해도 됩니다. 이는 HTTPS 대상에 연결하기 위한 터널을 HTTP 프록시 포트를 통해 만든다는 뜻입니다. 여기서 export는 현재 셸과 이후 실행되는 하위 프로세스에만 적용되며, 시스템 전체 설정을 바꾸지 않습니다. 환경 변수 이름 지원 여부는 도구마다 다를 수 있습니다.

더 알아보기: 앱 프록시 설정과 연결 문제 해결 방법은 도움말 센터에서 확인하세요.

7. TUN 모드란 무엇이며, 꼭 켜야 하나요?

TUN은 가상 네트워크 인터페이스로 트래픽을 받아들입니다. 라우팅 및 DNS 설정과 함께 사용하면 시스템 프록시를 읽지 않는 연결도 코어로 전달할 수 있습니다. TUN과 규칙 모드는 서로 다른 단계의 기능입니다. TUN은 트래픽을 코어에 넣는 방법을, 규칙은 코어에 들어온 트래픽의 출구를 결정합니다.

브라우저와 자주 사용하는 도구가 시스템 프록시를 통해 정상적으로 작동한다면, 설정을 ‘완벽하게’ 보이게 하려고 TUN을 켤 필요는 없습니다. 게임이나 일부 명령줄 프로그램 등 프록시 설정을 사용하지 않는 앱도 연결해야 할 때 클라이언트 안내에 따라 활성화하세요. Windows 클라이언트는 서비스 설치나 관리자 권한이 필요할 수 있으며, macOS와 Linux에서도 관련 권한 및 시스템 네트워크 설정이 필요할 수 있습니다.

TUN 활성화 전후 확인 사항

노드 문제를 TUN 문제로 오해하지 않도록 먼저 시스템 프록시 경로가 정상인지 확인하세요.
기존 VPN, 가상 네트워크 어댑터, 회사 네트워크 정책을 확인하세요. 여러 프로그램이 기본 경로를 변경하면 충돌할 수 있습니다.
활성화한 뒤 대상 연결이 클라이언트에 표시되는지 확인하고 LAN, DNS, IPv6 접속도 정상인지 점검하세요.
클라이언트를 종료한 뒤 네트워크가 복구되는지 확인하세요. 문제가 있으면 먼저 TUN을 끄고 남아 있는 라우팅 설정이나 서비스 상태를 점검하세요.

코어와 클라이언트에 따라 stack, auto-route, dns-hijack의 지원 여부와 기본값이 다릅니다. 인터넷에서 찾은 TUN 설정 전체를 구독 설정에 그대로 덮어쓰지 말고, TUN을 네트워크 권한 관리를 우회하는 수단으로 사용하지 마세요.

더 알아보기: 프로토콜 레퍼런스에서 TUN 필드를 확인하고, 라우팅 문제는 도움말 센터에서 점검하세요.

8. 구독을 업데이트한 뒤 사용자 지정 규칙이 사라지는 이유는 무엇인가요?

원격 구독을 업데이트하면 보통 서버에서 설정을 다시 가져옵니다. 다운로드한 YAML을 직접 편집하면 다음 업데이트 때 변경 사항이 덮어써질 수 있습니다. 구독 업데이트, 프록시 제공자 업데이트, 규칙 제공자 업데이트는 서로 다른 데이터 원본을 갱신하는 별개의 작업입니다.

원격 구독은 원본으로 유지하고, 사용자 지정 규칙을 보관하는 유일한 위치로 사용하지 마세요.
클라이언트에서 덮어쓰기, 병합, 스크립트 기능을 제공한다면 해당 기능에 로컬 변경 사항을 넣고 적용 범위를 확인하세요.
모든 설정을 직접 관리해야 한다면 로컬 설정으로 별도 저장하세요. 이 경우 서버 정보가 원격 구독 업데이트에 따라 자동으로 갱신되지 않는다는 점을 고려해야 합니다.
업데이트할 때마다 편집 창의 원본 내용만 확인하지 말고, 최종 적용된 설정을 점검하세요.

규칙을 덮어쓸 때는 삽입 위치에 특히 주의하세요. 사용자 지정 규칙을 MATCH 뒤에 추가하면 연결이 이미 기본 규칙에 전달돼 뒤쪽 규칙은 적용되지 않습니다. 존재하지 않는 프록시 그룹을 새 규칙에서 참조하면 설정을 불러오지 못할 수도 있습니다.

업데이트 주기의 단위도 확인하세요. 예를 들어 mihomo의 proxy-providers에서 interval: 3600은 3600초, 즉 1시간을 뜻합니다. 클라이언트 구독 페이지의 업데이트 주기는 분 단위로 표시될 수 있으므로 숫자만 그대로 옮기면 안 됩니다.

더 알아보기: 프로토콜 레퍼런스에서 제공자와 규칙 필드를 확인하고, 작업 절차는 빠른 시작을 참고하세요.

9. 로그인 시 자동 실행, 시작 후 프록시 활성화, 자동 업데이트는 같은 기능인가요?

아닙니다. 각 옵션은 서로 다른 동작을 제어합니다. ‘시작 프로그램 등록’을 켜면 보통 로그인 후 클라이언트만 실행됩니다. 코어 자동 실행, 시스템 프록시 활성화, TUN 복원 여부는 각각 따로 확인해야 합니다. 시스템 서비스를 설치해도 데스크톱 인터페이스가 로그인과 함께 열리는 것은 아닙니다.

설정 항목	확인할 결과
시작 프로그램 등록	로그인 후 클라이언트가 실행되는지
시작 시 시스템 프록시 활성화	시스템 프록시 주소와 포트가 현재 수신 중인 포트를 가리키는지
시작 시 TUN 복원	서비스 권한, 가상 인터페이스, 라우팅이 정상인지
구독 자동 업데이트	클라이언트에 설정된 조건에 따라 설정을 다시 가져오는지

설정을 마친 뒤에는 완전히 종료한 다음 다시 로그인하는 테스트를 한 번 이상 진행하세요. 먼저 코어 상태를 확인한 뒤 접속을 테스트하고, 시스템 트레이 아이콘만으로 작동 여부를 판단하지 마세요. 포터블 클라이언트의 폴더를 옮기면 시스템에 등록된 자동 실행 경로가 유효하지 않을 수 있으므로 다시 설정해야 합니다.

종료 후 브라우저에 프록시 연결 오류가 표시되면 운영체제의 프록시 설정에 127.0.0.1:7890이 남아 있는지 먼저 확인하세요. 로컬 포트는 닫혔는데 시스템이 여전히 해당 포트를 가리키면 ‘클라이언트를 종료했더니 오히려 인터넷이 안 되는’ 상황이 발생합니다.

더 알아보기: 빠른 시작에서 실행 순서를 확인하고, 종료 후 프록시 상태는 도움말 센터에서 점검하세요.

10. 인터넷에 연결할 수 없을 때 어떤 순서로 문제를 확인해야 하나요?

‘기본 네트워크 → 코어 포트 → 설정과 노드 → 분기 규칙 → 앱’ 순서로 단계별 확인하세요. DNS, 포트, 모드, 노드를 한꺼번에 바꾸는 것보다 원인을 찾기 쉽습니다. 한 번에 한 항목만 변경하고 변경 전후 결과를 기록하세요.

기본 네트워크: 시스템 프록시와 TUN을 잠시 끄고, 로컬 네트워크에서 원래 접속할 수 있던 사이트가 열리는지 확인하세요. 여전히 접속되지 않으면 Wi-Fi, 게이트웨이, 네트워크 인증부터 해결하세요.
코어 포트: 설정이 활성화됐는지, 코어가 실행 중인지, 포트가 일치하는지 확인하세요. 프록시를 명시한 명령어로 테스트하고 연결이 거부되면 먼저 로컬 포트 수신 상태를 점검하세요.
구독과 노드: 구독이 유효한지 확인한 뒤, 사용 가능하다고 알고 있는 다른 노드를 선택해 비교하세요. 설정을 파싱할 수 있다고 해서 서버에 현재 연결할 수 있는 것은 아닙니다.
분기 결과: 연결에 적용된 규칙과 프록시 체인을 확인하세요. 비교를 위해 잠시 전역 모드로 전환한 뒤 테스트가 끝나면 원래 모드로 되돌리세요. 전역 모드는 되지만 규칙 모드가 안 된다면 규칙에서 지정한 출구를 먼저 확인하세요.
DNS와 앱: 일부 도메인만 접속되지 않는다면 DNS 로그, 브라우저의 암호화 DNS, 캐시, 앱별 프록시 설정을 확인하세요. 모든 문제를 곧바로 DNS 탓으로 돌리지 마세요.

문의할 때 제공하면 좋은 정보

운영체제, 클라이언트 버전, 코어 버전, 현재 모드, TUN 사용 여부, 실제 수신 포트, 실패한 요청의 발생 시간과 민감 정보를 가린 로그를 알려 주세요. 모든 앱에서 문제가 발생하는지, 브라우저나 터미널 또는 특정 사이트에서만 발생하는지 함께 설명하면 원인을 찾는 범위를 크게 좁힐 수 있습니다.

더 알아보기: 도움말 센터에서 계속 문제를 확인하세요. 기본 설정을 다시 구성해야 한다면 빠른 시작에 따라 가져오기, 활성화, 출구 선택, 트래픽 유입 순서로 하나씩 검증하세요.