Clash Meta 초보자 FAQ 10가지: 구독 가져오기, 프록시 모드, 포트, 코어 한눈에 보기

1. Clash Meta, mihomo, 클라이언트는 어떤 관계인가요?

Clash Meta는 Clash를 기반으로 발전한 코어 프로젝트이며, 이후 mihomo라는 이름을 사용하게 되었습니다. 코어는 설정을 읽고 프록시 프로토콜을 처리하며, 규칙에 따라 트래픽을 분기하고 DNS를 조회합니다. 데스크톱 창, 구독 관리, 트레이 메뉴, 시스템 프록시 전환 기능은 보통 GUI 클라이언트가 제공합니다. 클라이언트를 설치했다고 해서 연결 가능한 프록시 노드까지 생기는 것은 아닙니다.

문제를 확인할 때는 클라이언트 버전, 코어 버전, 운영체제 버전을 각각 기록하세요. “Clash 최신 버전”만으로는 설정 호환성을 판단하기 어렵습니다. 같은 클라이언트라도 버전에 따라 포함된 mihomo 버전이 다를 수 있습니다.

• GUI에서 확인: 먼저 「설정」→「정보」에서 클라이언트 버전을 확인한 다음, 코어 정보나 시작 로그를 살펴보세요. 메뉴 이름은 클라이언트마다 다를 수 있습니다.
• 명령줄에서 확인: mihomo 실행 파일이 있는 폴더에서 mihomo -v를 실행하세요. Windows PowerShell에서는 .\mihomo.exe -v를 사용할 수 있습니다.
• 호환성 확인: “알 수 없는 필드” 또는 “지원하지 않는 프록시 유형” 오류가 나오면 구독을 계속 다시 가져오기보다 실제로 실행 중인 코어부터 확인하세요.

2. 구독은 어디서 받으며, 설치했는데 노드가 없는 이유는 무엇인가요?

구독은 서비스 제공업체나 설정 관리자가 제공하는 설정 접근 경로입니다. 흔히 접근 토큰이 포함된 HTTPS URL 형태입니다. 클라이언트는 이 주소에서 노드나 전체 설정을 가져옵니다. 클라이언트는 설정을 불러와 사용하는 역할을 할 뿐, 서버나 계정, 트래픽을 자동으로 제공하지 않습니다.

확인 위치: 이용 중인 서비스의 계정 페이지에서 「구독」 또는 「Clash / Clash Meta」 형식의 링크를 찾은 뒤, 클라이언트의 「구독」 또는 「프로필」 페이지로 돌아오세요. mihomo를 지원한다고 명시된 설정 형식을 우선 사용하고, 다른 프로토콜 링크만 들어 있는 텍스트를 완성된 YAML 설정으로 가져오지 마세요.

구독 만료와 노드 연결 실패는 서로 다른 문제입니다. 구독 문제는 설정을 다운로드할 때 발생하고, 노드 연결 문제는 설정을 불러온 뒤 프록시 연결을 시도할 때 발생합니다. 먼저 클라이언트가 설정을 정상적으로 가져왔는지 확인한 다음 노드 상태를 살펴보세요.

3. 구독은 어떻게 가져오며, 업데이트했는데 왜 달라진 게 없나요?

Clash Verge Rev 같은 데스크톱 클라이언트를 예로 들면, 보통 「구독」→「새로 만들기」→원격 구독 유형 선택→URL 입력→저장 순서로 진행합니다. 버전에 따라 구독 페이지에 링크 입력란이 바로 표시되기도 합니다. 버튼 이름보다 중요한 것은 다운로드, 선택, 적용 세 단계를 모두 마치는 것입니다.

1. 구독 주소 전체를 복사하고 앞뒤에 공백이나 줄바꿈이 섞이지 않았는지 확인하세요.
2. 원격 구독을 새로 추가해 다운로드한 뒤 HTTP 오류나 YAML 파싱 오류가 없는지 확인하세요.
3. 방금 가져온 설정을 선택하고 「프록시」 페이지에서 프록시 그룹이 표시되는지 확인하세요.
4. 한 번 직접 업데이트하고 업데이트 시각과 로그를 확인하세요. 다른 구형 설정이 현재 활성화되어 있지는 않은지도 살펴보세요.

다운로드 결과가 401 또는 403이면 토큰, 계정 상태, 서비스 제공업체의 제한을 확인하세요. 설정 대신 웹페이지가 내려오면 로그인 페이지 주소를 복사했을 수 있습니다. 파싱 오류에 표시된 줄 번호는 다운로드한 결과를 기준으로 하므로 로컬 오버라이드 파일의 줄 번호와 다를 수 있습니다.

업데이트 시 주의: 구독 캐시의 노드나 규칙을 직접 수정하면 다음 업데이트 때 덮어써질 수 있습니다. 변경 사항을 계속 유지하려면 클라이언트의 오버라이드, 설정 병합 또는 스크립트 기능을 사용하고, 최종 실행 설정도 확인하세요.

4. 규칙, 전역, 직접 연결 모드 중 무엇을 선택해야 하나요?

일상적인 사용에는 규칙 모드를 선택하세요. 설정의 rules는 위에서부터 순서대로 조건을 확인하고, 일치하는 규칙의 정책으로 연결을 보냅니다. 전역 모드는 코어로 들어온 연결을 전역 정책으로 보내고, 직접 연결 모드는 코어로 들어온 연결을 대상에 바로 연결합니다. 여기서 전제는 “트래픽이 이미 코어에 들어온 상태”라는 점입니다.

설정 위치: 클라이언트의 「프록시」 페이지나 트레이 메뉴에서 모드를 선택하세요. 전역 모드로 바꾼 뒤에도 전역 정책에 사용 가능한 노드를 선택해야 합니다. DIRECT를 선택하면 연결은 계속 직접 연결됩니다. 전역 모드라고 해서 모든 앱의 트래픽이 자동으로 프록시를 거치는 것은 아닙니다.

5. 7890 포트란 무엇이며, 노드 포트와는 어떻게 다른가요?

7890은 설정 예시에 자주 쓰이는 로컬 프록시 수신 포트입니다. 반드시 이 값을 써야 하는 것은 아니며, 원격 서버 포트도 아닙니다. 설정이 mixed-port: 7890이면 하나의 로컬 포트에서 HTTP 프록시와 SOCKS 프록시 연결을 모두 받을 수 있습니다. 실제 포트는 클라이언트의 실행 설정을 기준으로 확인하세요.

mixed-port: 7890
allow-lan: false
mode: rule
log-level: info

확인 위치: 클라이언트 설정의 「포트」 또는 「혼합 포트」를 확인하거나 현재 실행 설정에서 mixed-port를 검색하세요. 외부 컨트롤러 포트를 프록시 포트와 혼동하지 마세요. external-controller는 관리 인터페이스를 제공하는 항목이며, 브라우저의 HTTP 프록시 주소로 사용할 수 없습니다.

Windows에서 아래 명령을 실행하면 로컬에서 7890 포트를 수신 중인 프로세스가 있는지 확인할 수 있습니다. 결과가 표시되어도 수신 프로세스가 현재 클라이언트라는 뜻은 아니므로 PID를 추가로 확인해야 합니다.

netstat -ano | findstr ":7890"

시작 로그에 address already in use가 표시되면 다른 프록시 프로세스를 종료하거나 로컬 수신 포트를 변경한 뒤, 해당 포트를 사용하는 앱 설정도 함께 수정하세요.

6. 시스템 프록시를 켰는데도 터미널이나 게임에서 프록시가 적용되지 않는 이유는 무엇인가요?

시스템 프록시는 운영체제가 앱에 제공하는 프록시 설정이지, 트래픽을 강제로 가로채는 기능은 아닙니다. 이 설정을 사용할지는 앱에 따라 다릅니다. 브라우저는 보통 시스템 프록시를 사용할 수 있지만, 명령줄 도구는 환경 변수를 읽거나 자체 프록시 옵션만 지원할 수 있습니다. UDP를 주로 사용하는 게임은 일반 HTTP 시스템 프록시만으로 해결되지 않을 수 있습니다.

확인 위치: 먼저 클라이언트에서 「시스템 프록시」를 켜고, Windows 11의 「설정」→「네트워크 및 인터넷」→「프록시」에서 로컬 프록시 주소를 확인하세요. 그런 다음 클라이언트의 「연결」 페이지에서 대상 앱이 시작한 연결을 살펴보세요. macOS에서는 「시스템 설정」→「네트워크」→현재 네트워크 서비스→「세부사항」→「프록시」에서 확인할 수 있습니다.

터미널에서는 전역 환경 변수를 바로 변경하지 말고, 먼저 한 번만 명시적으로 프록시를 지정해 테스트하세요. 아래 명령은 혼합 포트가 실제로 7890이라고 가정합니다. Windows에서는 curl.exe를 사용하면 일부 PowerShell 환경에서 발생하는 명령 별칭 차이를 피할 수 있습니다.

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

macOS 또는 Linux에서는 명령의 curl.exe를 curl로 바꾸세요. 프록시를 명시적으로 지정하면 성공하지만 일반 접속은 실패한다면, 코어를 다시 설치하기보다 앱이 프록시 설정을 읽는지 먼저 확인하세요.

7. TUN 모드는 언제 켜야 하나요?

TUN은 가상 네트워크 인터페이스와 라우팅 설정을 통해 트래픽을 전달합니다. 시스템 프록시를 사용하지 않는 프로그램이나 더 많은 네트워크 트래픽을 처리해야 하는 경우에 적합합니다. 노드 속도를 높이는 스위치가 아니며, 구독 만료나 서버 장애, 잘못된 트래픽 분기 문제를 자동으로 해결하지 않습니다.

설정 위치: 클라이언트 「설정」에서 「TUN 모드」 또는 「가상 네트워크 어댑터」 항목을 켜세요. Windows 클라이언트는 서비스 모드 설치나 관리자 권한이 필요할 수 있습니다. Android는 보통 시스템 VPN 권한으로 트래픽을 연결하므로 데스크톱 메뉴를 그대로 따라 할 수 없습니다.

1. 먼저 TUN을 끈 상태에서 명시적 프록시로 노드가 작동하는지 확인하세요.
2. 현재 시스템 프록시, DNS, 다른 VPN의 상태를 기록한 다음 TUN을 켜세요.
3. 대상 앱 하나를 테스트하고 「연결」 페이지에 해당 기록이 표시되는지 확인하세요.
4. 로컬 네트워크나 회사 VPN에 문제가 생기면 TUN을 꺼서 결과를 비교한 뒤 라우팅 충돌과 우회 범위를 확인하세요.

8. DNS와 fake-ip는 무엇이며 직접 설정을 바꿔야 하나요?

DNS는 도메인 이름을 IP 주소로 변환합니다. mihomo의 DNS 모듈은 도메인과 연결의 연관 관계에도 관여합니다. fake-ip 모드에서는 코어가 앱에 가상 주소를 반환하고 해당 주소와 도메인의 매핑을 보관합니다. 이 주소는 대상 서버의 실제 공인 IP가 아닙니다.

일반적인 설정에서는 198.18.0.1/16을 fake-ip 범위로 사용합니다. 해당 범위의 주소가 보인다고 해서 노드가 오염되었거나 서버 주소가 잘못되었다고 바로 판단하지 마세요. 먼저 enhanced-mode: fake-ip가 활성화되어 있는지 확인하세요.

확인 위치: 현재 실행 설정의 dns 섹션과 클라이언트의 DNS 오버라이드 설정을 확인하세요. 브라우저의 암호화 DNS, 시스템 DNS, 코어 DNS는 서로 다른 경로를 사용할 수 있습니다. 따라서 시스템에서 한 번 조회한 결과만으로 앱이 어떤 리졸버를 사용했는지 단정할 수 없습니다.

• 특정 도메인에서만 문제가 발생하면 연결 로그에 표시된 도메인, 적용 규칙, DNS 오류를 먼저 확인하세요.
• 실제 IP가 필요한 로컬 네트워크 서비스는 도메인별로 fake-ip-filter 사용 여부를 검토하세요. 제외 범위를 한꺼번에 너무 넓게 설정하지 마세요.
• DNS를 변경한 뒤에는 앱 연결을 새로 설정하세요. 기존 연결이나 앱 캐시에 이전 결과가 남아 있을 수 있습니다.

9. 사용자 지정 규칙은 어디에 추가하며, 왜 적용되지 않나요?

규칙은 보통 위에서 아래 순서로 확인하며, MATCH는 흔히 마지막 대체 규칙으로 사용합니다. 아래는 규칙 일부일 뿐, 단독으로 실행할 수 있는 완성된 설정은 아닙니다. 예시 도메인은 직접 연결하고 나머지 연결은 「프록시 선택」이라는 정책으로 보냅니다. 이 정책은 proxy-groups에 미리 정의되어 있어야 합니다.

rules:
  - DOMAIN-SUFFIX,example.com,DIRECT
  - MATCH,프록시 선택

설정 위치: 클라이언트의 설정 오버라이드 메뉴에서 규칙을 추가한 다음, 병합된 실행 설정을 확인해 새 규칙이 대체 규칙보다 앞에 있는지 살펴보세요. 수정 후 설정을 다시 불러오고 「연결」 페이지에서 규칙 유형, 정책 경로, 실제 트래픽 출구를 확인하세요.

규칙이 계속 적용되지 않으면 다음 세 가지를 차례로 확인하세요. 현재 규칙 모드인지, 앱이 실제로 연결한 도메인이 예상한 것과 일치하는지, 트래픽이 해당 클라이언트로 들어오는지 확인합니다. IP로 직접 연결하는 경우, 앱 자체의 DNS 처리 방식, 이미 유지 중인 연결이 확인 결과에 영향을 줄 수 있습니다.

rule-providers를 사용한다면 규칙 세트를 정상적으로 다운로드했는지, rules에 해당하는 RULE-SET 참조가 있는지도 확인하세요. 규칙 세트의 출처를 선언하는 것만으로 규칙 매칭에 사용되는 것은 아닙니다.

10. 노드 지연 시간은 정상인데 웹페이지가 열리지 않을 때는 어떤 순서로 확인해야 하나요?

지연 시간 테스트는 보통 설정이나 클라이언트에서 지정한 테스트 주소에만 요청을 보냅니다. 특정 요청의 결과를 보여줄 뿐, 모든 웹사이트와 UDP, 로그인 과정이 정상이라는 뜻은 아닙니다. “설정 → 진입 경로 → 규칙 → 노드 → 대상” 순서로 확인하세요.

1. 설정이 정상적으로 불러와졌는지 확인: 「로그」에서 YAML 파싱 실패, 정책 그룹 누락, 포트 충돌이 없는지 살펴보세요. 명령줄 사용자는 mihomo -t -f config.yaml을 실행해 설정을 검사할 수 있습니다. 검사를 통과해도 원격 노드에 연결할 수 있다는 뜻은 아닙니다.
2. 트래픽이 들어오는지 확인: 프록시를 명시해 요청을 보낸 다음 「연결」을 확인하세요. 대상 기록이 없다면 앱의 프록시 주소, 실제 수신 포트, TUN의 트래픽 처리 여부를 확인하세요.
3. 규칙과 출구를 확인: 연결에 적용된 규칙과 최종 노드를 확인하세요. 전역 모드로 잠시 전환한 뒤 같은 노드를 직접 선택해 결과를 비교하세요.
4. 대상별 차이 확인: 같은 노드로 서로 다른 웹사이트 두 곳을 테스트하세요. 특정 웹사이트만 실패한다면 대상 서비스의 제한, DNS, 출구 연결 상태를 확인하세요.
5. 유효한 증거를 남기세요: 클라이언트와 코어 버전, 오류 시각, 모드, 대상 도메인, 민감 정보를 가린 로그를 기록하세요. 테스트 한 번을 마친 뒤 다음 항목을 변경하세요.

설정 절차를 더 확인하려면 입문 가이드를 참고하세요. 오류 증상에 따라 원인을 찾으려면 문제 해결을 이용하세요. 문의하기 전에 구독 토큰, 노드 인증 정보, 제어 인터페이스 키를 삭제하세요.