Clash Meta 빠른 시작: 가져오기, 연결 및 검증

시작하기 전에 두 가지를 준비해야 합니다. 현재 시스템에 맞는 Clash Meta 클라이언트와 서비스 제공업체가 제공한 구독 주소 또는 로컬 YAML 설정 파일입니다. 클라이언트는 설정을 읽고 연결을 전달할 뿐이며, 클라이언트를 설치한다고 사용할 수 있는 노드가 자동으로 생기지는 않습니다. 계정 정보만 있고 구독 주소가 없다면 먼저 서비스 제공업체의 관리 패널에서 Clash, Mihomo 또는 범용 구독 메뉴를 찾으세요.

처음 설치할 때는 그래픽 클라이언트로 진행하는 것이 좋습니다. Windows와 macOS 사용자는 다운로드 페이지에서 Clash Plus, Clash Verge Rev 또는 현재 유지 관리되는 다른 클라이언트를 선택할 수 있습니다. Android에서는 Clash Plus, Clash Meta for Android 등을 사용할 수 있습니다. Linux 데스크톱에서는 그래픽 클라이언트를 사용하면 되며, 서버나 라우터 환경에서만 mihomo 커널 직접 실행을 고려하세요. 커널 직접 실행에는 설정 경로, 서비스 관리 및 투명 프록시 설정이 필요하므로 이 10분 가이드의 범위를 벗어납니다.

설치가 끝나면 시스템 날짜, 시간 및 시간대가 정확한지 먼저 확인하세요. 구독 업데이트, HTTPS 연결 및 인증서 검증은 시스템 시간에 의존하므로 시간이 크게 어긋나면 구독 다운로드 실패, 인증서 오류 또는 웹페이지 접속 불가로 나타날 수 있습니다. 이어서 시스템 프록시를 변경하는 다른 도구를 잠시 종료해 프록시 설정을 두 프로그램이 동시에 차지하지 않도록 하세요. 이전 클라이언트가 백그라운드에서 실행 중이라면 완전히 종료한 뒤 현재 사용할 클라이언트를 시작하세요.

클라이언트를 연 뒤 먼저 “구독”, “설정”, “설정 파일” 또는 “Profiles” 페이지를 찾으세요. 이곳에는 실시간 프록시 노드 목록이 아니라 클라이언트에서 전환할 수 있는 설정 항목이 저장됩니다. 추가 메뉴를 찾았다면 “URL에서 가져오기”, “구독 추가” 또는 비슷한 기능을 선택하고 서비스 제공업체가 제공한 전체 구독 주소를 입력란에 붙여넣으세요. 주소 앞뒤에 불필요한 공백이 없는지 확인한 뒤 가져오기, 다운로드 또는 저장을 누릅니다.

가져오기가 완료되면 보통 새 설정 항목과 설정 이름, 업데이트 시간 또는 업데이트 버튼이 표시됩니다. 먼저 해당 항목을 눌러 현재 설정으로 지정하세요. 일부 클라이언트는 체크 표시, 강조 테두리 또는 “활성화됨” 문구로 선택 상태를 표시하고, 다른 클라이언트는 가져오기가 끝나면 자동으로 전환합니다. “가져오기 성공” 안내만으로 판단하지 말고 현재 사용 중인 항목이 방금 추가한 설정인지 확인하세요. 그렇지 않으면 이후의 정책 그룹이 이전 설정에서 계속 불러와질 수 있습니다.

이어서 수동 업데이트를 한 번 실행하세요. 업데이트가 성공했다는 것은 클라이언트가 구독 주소에 접근할 수 있고 응답 내용을 Clash 설정으로 해석할 수 있다는 뜻입니다. 형식 오류가 표시되면 웹페이지 주소, 로그인 페이지 주소 또는 QR 코드 설명 문구를 구독 주소로 입력하지 않았는지 먼저 확인하세요. 시간 초과가 표시되면 로컬 네트워크를 한 번 바꿔 다시 시도할 수 있습니다. 구독이 비어 있다고 나오면 서비스 제공업체에 문의해 요금제 상태와 구독 유형을 확인하세요. 이 단계에서는 YAML을 바로 수정하지 않는 것이 좋습니다. 첫 연결의 목표는 원본 설정이 그대로 작동하는지 확인하는 것이기 때문입니다.

로컬 파일을 사용할 때는 “파일에서 가져오기”를 선택하고 확장자가 .yaml 또는 .yml인 설정 파일을 고르세요. 가져온 뒤에는 동일하게 현재 설정으로 지정해야 합니다. YAML은 들여쓰기에 민감하므로 메신저, 웹 편집기 또는 텍스트 변환을 거치면 공백 구조가 달라질 수 있습니다. 클라이언트에서 파싱 오류가 발생하면 먼저 원본 파일을 다시 가져오세요. proxies, proxy-groups, rules 또는 dns를 필드별로 확인해야 한다면 설정 파일 구조 설명으로 이동하세요.

노드 목록이 표시된 뒤 다음 단계로 진행하세요

설정을 선택한 뒤 “프록시”, “정책” 또는 “Proxies” 페이지로 이동하세요. 정상이라면 여러 정책 그룹이 표시되고, 그룹을 펼치면 노드 이름이나 하위 정책을 볼 수 있습니다. 페이지가 완전히 비어 있다면 현재 설정이 제대로 로드되지 않은 것이므로 시스템 프록시를 켜도 예상한 결과를 얻을 수 없습니다. 먼저 설정 페이지로 돌아가 항목을 다시 선택하고 오류 안내를 확인하세요. 정책 페이지에 설정 내용이 표시될 때까지 진행한 뒤 모드를 선택합니다.

설정이 로드되면 다음으로 트래픽을 어떻게 분배할지 결정합니다. 일반적인 클라이언트에는 “규칙”, “글로벌”, “직접 연결” 세 가지 모드가 있으며 영어로는 보통 Rule, Global, Direct라고 표시됩니다. 처음에는 규칙 모드를 선택하는 것이 좋습니다. 규칙 모드는 설정에 정의된 순서에 따라 도메인, IP, 앱 또는 네트워크 유형을 판단한 뒤 해당 연결을 정책 그룹으로 전달합니다. 일반 웹사이트는 직접 연결하고 프록시가 필요한 연결은 선택한 노드로 보냅니다.

글로벌 모드는 대부분의 연결을 하나의 프록시 정책으로 전달하므로 특정 웹사이트가 분할 규칙 때문에 실패하는지 임시로 확인할 때 유용합니다. 하지만 모든 문제를 조사할 때 첫 단계로 사용할 필요는 없습니다. 직접 연결 모드는 프록시를 우회해 문제가 클라이언트 경로에서 발생하는지 확인할 수 있습니다. 세 모드는 속도 설정이 아니며 노드 회선 품질도 바꾸지 않습니다. 연결이 어느 경로로 이동할지만 결정합니다. 처음 설정을 마친 뒤에는 규칙 모드를 유지하고, 특정 웹사이트에 문제가 생길 때만 잠시 모드를 바꿔 비교하세요.

규칙 모드를 선택한 뒤 “노드 선택”, “프록시”, “PROXY” 또는 “수동 선택”과 비슷한 이름의 주요 정책 그룹을 펼치세요. 서비스 상태가 정상인 노드를 선택한 다음 해당 노드 옆에 테스트 기능이 있는지 확인합니다. 지연 시간 테스트는 클라이언트가 노드와 기본 통신을 수립할 수 있는지 확인하는 용도입니다. 수치가 낮으면 왕복 시간이 짧다는 뜻인 경우가 많지만 실제 다운로드 속도를 의미하지 않으며 모든 대상 웹사이트에 접속할 수 있다는 증거도 아닙니다. 테스트가 실패하면 다른 노드로 바꿔 보세요. 여러 노드가 모두 실패한다면 구독 상태, 로컬 네트워크 또는 클라이언트 권한 문제일 가능성이 높습니다.

설정에는 “자동 선택”, “장애 조치”, “로드 밸런싱” 등의 정책 그룹이 포함될 수도 있습니다. 처음 연결할 때 하나씩 조정할 필요는 없습니다. 먼저 주요 프록시 정책이 확실히 사용할 수 있는 노드를 가리키게 하면 점검 변수를 줄일 수 있습니다. 기본 연결을 확인한 뒤 필요에 따라 자동 테스트나 장애 조치를 사용하세요. 정책 그룹은 서로 참조할 수 있으므로 페이지의 특정 옵션이 최종 노드가 아니라 다른 정책 그룹일 수도 있으며, 이는 정상적인 설정 구조입니다.

노드와 모드를 정한 뒤 클라이언트 홈 화면이나 설정 화면으로 돌아가 “시스템 프록시”, “시스템 프록시로 설정” 또는 System Proxy 스위치를 찾아 켜세요. 이 작업은 시스템 프록시 주소를 클라이언트가 수신 대기 중인 로컬 포트로 지정합니다. 이후 브라우저와 시스템 프록시 설정을 따르는 앱의 연결이 Clash로 전달됩니다. 클라이언트는 계속 실행 중이어야 합니다. 클라이언트를 바로 종료했는데 시스템 프록시가 복원되지 않으면 브라우저가 더 이상 수신 대기하지 않는 로컬 포트를 가리켜 인터넷에 연결되지 않을 수 있습니다.

Windows에서 처음 활성화할 때 시스템 방화벽이 클라이언트의 네트워크 접근을 허용할지 물을 수 있습니다. 프로그램 출처가 현재 설치 파일과 일치하는지 확인한 뒤 실제 사용할 네트워크 유형에 필요한 권한을 부여하세요. macOS에서는 시스템 암호 입력이나 네트워크 확장 및 프록시 설정 변경 승인이 필요할 수 있습니다. Android와 iOS에서는 보통 VPN 연결 권한 안내가 표시됩니다. 시스템이 로컬 VPN 인터페이스를 통해 클라이언트로 트래픽을 전달하기 때문입니다. 이러한 안내는 운영체제가 네트워크 연결 경로를 설정하는 과정이므로 승인을 완료하지 않으면 클라이언트 화면에 실행 중으로 표시되어도 다른 앱의 연결을 받지 못할 수 있습니다.

먼저 시스템 프록시만 사용해 브라우저를 테스트하고 TUN, DNS 및 포트는 동시에 바꾸지 마세요. 시스템 프록시 경로가 더 짧아 문제가 생겼을 때 원인을 파악하기 쉽습니다. 기존 페이지를 새로 고치기만 하지 말고 새 브라우저 창을 여세요. 브라우저가 기존 연결을 재사용할 수 있기 때문입니다. 먼저 평소 직접 연결되는 웹사이트에 접속해 로컬 네트워크가 전체적으로 끊기지 않았는지 확인한 다음, 프록시 정책을 거쳐야 하는 대상 웹사이트에 접속하세요. 두 종류의 웹사이트가 모두 열리면 검증 단계로 넘어갈 수 있습니다.

TUN 모드를 켜야 하는 경우

일부 앱은 시스템 프록시 설정을 읽지 않습니다. 예를 들면 일부 게임 런처, 명령줄 프로그램, 스토어 앱 또는 자체 네트워크 스택을 구현한 소프트웨어가 그렇습니다. 브라우저는 정상인데 이런 앱만 클라이언트를 거치지 않는다면 TUN 모드를 고려하세요. TUN은 가상 네트워크 인터페이스를 만들고 더 넓은 범위의 트래픽을 인계하므로 관리자 권한, 시스템 서비스 또는 네트워크 확장 지원이 필요할 수 있습니다. 켜기 전에 현재 정상 작동 상태를 저장해 두면 문제가 생겼을 때 TUN을 끄고 시스템 프록시만 사용하는 기준 상태로 빠르게 돌아갈 수 있습니다.

TUN을 활성화한 뒤 서비스 설치, 네트워크 확장 승인 또는 클라이언트 재시작 안내가 표시되면 지시에 따라 완료한 뒤 TUN 스위치가 계속 켜져 있는지 확인하세요. 가상 네트워크 카드를 제공하는 프록시 도구 두 개를 동시에 켜지 말고, 이전 VPN이 기본 경로를 장시간 점유하게 두지도 마세요. 고급 stack, 자동 라우팅, 엄격한 라우팅 및 DNS 하이재킹 설정은 시스템마다 다르므로 관련 필드는 TUN 및 공통 필드 설명에서 확인할 수 있습니다.

tun:
  enable: true
  stack: mixed
  auto-route: true

연결 성공 여부를 스위치 색상만으로 판단해서는 안 됩니다. 신뢰할 수 있는 검증에는 외부 접속 결과와 클라이언트 내부 기록이 모두 포함되어야 합니다. 먼저 새 브라우저 창을 열고 현재 설정상 프록시를 거쳐야 하는 웹사이트에 접속해 페이지가 완전히 로드되는지 확인하세요. 그런 다음 보통 직접 연결되는 웹사이트에 접속해 규칙 모드에서 로컬 연결이 정상인지 확인합니다. 한 페이지만 테스트하면 브라우저 캐시, 기존 연결 또는 웹사이트 자체 장애를 프록시 결과로 잘못 판단할 수 있습니다.

이어서 클라이언트의 “연결”, “로그” 또는 “Connections” 페이지를 열고 방금 웹페이지를 새로 고치세요. 정상이라면 새 연결 기록이 표시되며, 보통 대상 도메인, 사용 프로토콜, 일치한 규칙 및 최종 정책이 포함됩니다. 중요한 것은 연결 수가 아니라 대상 도메인이 나타났는지, 그리고 어떤 정책 그룹이나 노드로 전달되었는지입니다. 기록에 DIRECT가 표시되면 현재 규칙이 직접 연결을 선택한 것입니다. 선택한 프록시 노드가 표시되면 트래픽이 프록시 경로로 들어간 것입니다.

웹페이지는 열리지만 기록에 새 연결이 전혀 없다면 먼저 현재 실행 중인 클라이언트를 보고 있는지 확인하세요. 다른 백그라운드 인스턴스일 수 있습니다. 그런 다음 브라우저에 별도 프록시가 설정되어 있는지, 시스템 프록시를 우회하는 네트워크 기능이 켜져 있는지, 클라이언트의 시스템 프록시 스위치가 여전히 켜져 있는지 점검하세요. 명령줄 도구는 시스템 프록시를 기본적으로 무시할 수도 있으므로 브라우저 테스트는 정상인데 터미널 요청 기록이 없는 것은 모순이 아닙니다. 명령줄에서 프록시를 사용하려면 해당 도구의 프록시 옵션이나 환경 변수로 직접 설정하세요.

연결 기록은 나타나지만 웹페이지에 접속할 수 없다는 안내가 표시되면 해당 연결의 규칙 결과와 오류 유형을 확인하세요. 시간 초과라면 다른 노드와 비교하고, 연결 거부라면 노드 서비스, 대상 포트 또는 로컬 방화벽 문제일 수 있습니다. 도메인 확인에 실패하면 DNS 경로를 점검해야 합니다. 먼저 같은 정책 그룹의 다른 노드로 바꾼 뒤 웹페이지를 다시 여세요. 새 노드에서 정상이라면 원래 노드에 문제가 있는 것입니다. 모든 노드에서 결과가 같다면 클라이언트를 반복해서 재설치하기보다 구독, 네트워크 및 DNS를 점검하세요.

처음 설정에 실패했을 때 클라이언트를 재설치하고, 설정을 교체하고, DNS를 수정하고, 여러 노드를 동시에 바꾸지 마세요. 한 번에 너무 많이 변경하면 비교 기준을 잃게 됩니다. 더 효과적인 순서는 설정 진입점부터 “구독—정책—노드—시스템 프록시—앱—DNS”를 따라 단계별로 확인하는 것입니다. 각 항목을 점검할 때마다 같은 대상 웹페이지를 다시 테스트하고 연결 기록이 달라졌는지 확인하세요.

위 순서로도 원인을 찾지 못했다면 클라이언트 이름, 운영체제, 현재 모드, 문제가 발생한 구체적인 단계 및 로그의 첫 번째 명확한 오류를 기록한 뒤 Clash 설정 파일 전체 레퍼런스를 참고하세요. 상세 문서에서는 포트, DNS, 프록시 노드, 정책 그룹, 규칙 문법 및 오버라이드 병합을 계속 설명합니다. 이 빠른 가이드는 첫 연결을 완료하는 데 필요한 최소 절차에 집중합니다.