FIRST CONNECTION / MIHOMO

Clash 구독 가져오기 및 연결 가이드

구독 가져오기, 규칙 모드 선택, 트래픽 전달 시작, 실제 요청 확인까지 4단계로 첫 설정을 마칩니다. 클라이언트와 유효한 구독이 준비되어 있다면 약 10분 안에 기본 점검을 완료할 수 있습니다.

시작 전: 클라이언트와 구독 준비

먼저 mihomo 호환 클라이언트를 설치하고 서비스 제공업체가 제공한 Clash 형식 구독 링크나 YAML 설정 파일을 준비합니다. 클라이언트는 설정을 불러와 코어를 실행하고 트래픽을 전달하며, 구독에는 프록시 서버와 정책 그룹, 규칙 등이 포함됩니다. 클라이언트만 설치한다고 연결 가능한 서버가 생기는 것은 아니며, 이 가이드에서는 공유 구독을 제공하지 않습니다. 구독 출처와 유효 기간, 기기 사용 제한을 확인한 뒤 가져오세요.

처음 설정할 때는 프록시 클라이언트를 하나만 실행하는 것이 좋습니다. 다른 프록시 도구의 시스템 프록시, TUN 또는 VPN 연결을 끄고 현재 정상 작동하는 네트워크 환경을 유지하세요. 기기가 조직에서 관리된다면 프록시 변경이나 가상 네트워크 어댑터 생성이 허용되는지 먼저 확인합니다. 테스트 후 복구할 수 있도록 기존 수동 프록시 설정을 기록해 두세요. 연결 문제를 확인한다는 이유로 시스템 방화벽을 바로 끄지는 마세요.

이어서 복잡한 규칙은 변경하지 않고 최소한의 연결 경로를 설정합니다. 처음에는 구독에 포함된 정책 그룹과 규칙을 그대로 사용하고, 연결이 확인된 뒤 DNS, 자동 지연 시간 테스트 또는 규칙 세트를 조정하세요. 운영체제별 설치 권한과 서비스 모드, 설정 경로는 전체 플랫폼 설치 및 설정 가이드를 참고하세요. 이 페이지에서는 첫 연결 절차를 이어서 진행합니다.

STEP 01 / PROFILE

구독을 가져오고 설정 활성화

클라이언트의 “설정” 또는 “구독” 페이지를 열고 “새로 만들기”, “추가” 또는 “URL에서 가져오기”를 선택합니다. 주소 입력란에 구독 URL 전체를 붙여 넣고 알아보기 쉬운 이름을 지정하세요. 구독 주소는 서비스 제공업체가 Clash 또는 mihomo 설정용으로 안내한 링크여야 합니다. 계정 로그인 페이지나 결제 페이지, 브라우저 주소창의 임의 링크는 사용할 수 없습니다. 붙여 넣은 뒤 앞뒤 공백과 줄바꿈을 확인하되, URL의 쿼리 매개변수는 임의로 삭제하지 마세요.

“다운로드” 또는 “가져오기”를 누르고 완료 메시지가 표시될 때까지 기다립니다. 정상적으로 처리되면 설정 목록에 항목이 추가되고 업데이트 시간이나 원격 설정 출처가 함께 표시될 수 있습니다. 그런 다음 해당 항목의 “사용”, “활성화” 버튼을 누르거나 설정 카드를 선택하세요. 가져오자마자 자동으로 활성화되는 클라이언트도 있지만 파일만 저장하는 클라이언트도 있습니다. 목록에 이름이 추가됐는지만 보지 말고 현재 설정 표시와 프록시 페이지에 구독의 정책 그룹이 나타나는지 확인하세요.

로컬 .yaml 또는 .yml 파일을 받았다면 “파일에서 가져오기”를 선택해 해당 파일을 불러오세요. 파일 내용을 구독 URL 입력란에 붙여 넣을 필요는 없습니다. 로컬 설정은 자동으로 업데이트되지 않을 수 있으며, 원격 프록시 목록이나 규칙 목록을 참조하는 경우 실행 중 외부 리소스를 다운로드해야 할 수도 있습니다. 파일을 선택할 수 있다는 것은 가져오기 메뉴가 맞다는 뜻일 뿐, 코어가 설정을 정상적으로 해석하고 불러왔는지는 별도로 확인해야 합니다.

활성화한 뒤 “프록시” 페이지로 이동해 정책 그룹이나 노드가 표시되는지 확인합니다. 이름은 구독 작성자가 정하며 “노드 선택”, “프록시” 또는 PROXY 등으로 표시될 수 있습니다. 페이지가 비어 있다면 설정 페이지로 돌아가 방금 가져온 설정이 실제로 선택되어 있는지 확인한 다음, 로그에서 다운로드 또는 파싱 오류를 살펴보세요. 다운로드된 내용이 웹페이지이거나 설정 형식이 호환되지 않거나 들여쓰기가 잘못된 경우, 목록에는 설정이 보여도 코어에서 사용할 수 없을 수 있습니다.

처음 다운로드에 실패하면 기기가 인터넷에 연결되는지 확인한 다음 서비스 제공업체에 문의해 구독 상태와 주소가 올바른지 확인하세요. 다른 설정 형식으로 계속 바꿔 보거나 다운로드 문제를 가리기 위해 바로 전역 프록시를 켜지 마세요. 문제를 해결한 뒤 설정 목록에서 한 번 수동으로 업데이트하세요. 업데이트 성공과 설정 활성화를 확인한 다음 다음 단계로 넘어갑니다. 이후 구독 업데이트로 노드 이름이 바뀌면 정책 그룹에서 현재 선택 항목도 다시 확인해야 합니다.

STEP 02 / ROUTING

규칙 모드와 아웃바운드 노드 선택

클라이언트 홈 화면이나 프록시 페이지 상단, 설정에서 “모드”를 찾아 Rule을 선택하세요. 한국어 인터페이스에서는 보통 “규칙”으로 표시됩니다. 규칙 모드는 설정에 지정된 매칭 순서에 따라 직접 연결, 프록시 또는 다른 아웃바운드 정책을 선택하므로 일상적인 사용을 시작하기에 적합합니다. 모드를 선택한 뒤 구독의 기존 규칙을 유지하세요. 처음 연결할 때 rules 전체를 새로 작성할 필요는 없습니다.

모드 처리 방식 첫 설정 권장 사항
Rule / 규칙 설정 규칙에 따라 아웃바운드 정책을 선택합니다. 먼저 사용하고 구독의 기본 규칙을 유지하세요.
Global / 전역 코어가 받은 트래픽을 전역 정책에 따라 처리합니다. 짧은 비교 테스트에만 사용한 뒤 규칙 모드로 되돌리세요.
Direct / 직접 연결 코어가 받은 트래픽을 직접 연결로 내보냅니다. 프록시 노드의 연결 여부를 확인할 때는 사용하지 마세요.

모드 설정과 트래픽 전달 설정은 서로 독립적입니다. 규칙 모드는 “코어에 들어온 트래픽을 어떻게 처리할지” 결정하고, 시스템 프록시나 TUN은 “어떤 트래픽을 코어에 전달할지” 결정합니다. 따라서 전역 모드로 바꿔도 시스템 프록시를 사용하지 않는 명령줄 프로그램이 자동으로 클라이언트를 거치는 것은 아닙니다. TUN을 켜더라도 모든 대상이 프록시를 사용하는 것은 아니며, 최종 경로는 현재 모드와 규칙에 따라 결정됩니다.

이어서 “프록시” 페이지로 이동해 주요 정책 그룹을 펼칩니다. 그룹 안에 수동 선택 목록이 있으면 구독에 포함된 노드 하나를 선택하세요. “자동 선택” 같은 하위 그룹이 중첩되어 있다면 하위 그룹의 선택 결과도 확인해야 합니다. 노드 이름이 강조 표시되는지만 보지 말고 접속 규칙이 해당 정책 그룹을 참조하는지도 확인하세요. DIRECT는 직접 연결을 뜻하며, 이를 선택하면 원격 프록시 서버를 거치지 않습니다.

“지연 시간 테스트”, “속도 테스트” 또는 이에 해당하는 버튼을 찾아 한 번 실행합니다. 테스트 결과가 표시되면 해당 조건에서 노드 응답을 확인했다는 뜻이지만, 모든 웹사이트나 UDP 요청, 장시간 다운로드까지 성공한다는 의미는 아닙니다. 시간 초과는 테스트 주소나 현재 네트워크 때문일 수도 있습니다. 처음에는 숫자가 가장 낮은 노드만 고집하지 말고 테스트를 통과한 노드를 선택하세요. 실제 접속과 연결 기록은 4단계에서 확인합니다.

이 단계를 마치면 현재 규칙 모드가 선택되어 있고 주요 프록시 정책 그룹에서 노드나 자동 선택 그룹이 지정되어 있는지 확인할 수 있어야 합니다. 대상 웹사이트의 트래픽을 어떤 그룹이 처리하는지 모르겠다면 구독의 기본 선택을 유지하고 연결한 뒤 적용 규칙 기록을 확인하세요. 규칙 우선순위와 중첩 정책 그룹, 자동 선택 매개변수에 관한 자세한 설명은 설정 가이드에서 확인할 수 있습니다. 첫 연결 단계에서 모든 내용을 살펴볼 필요는 없습니다.

STEP 03 / TRAFFIC CAPTURE

코어를 실행하고 트래픽 전달 시작

클라이언트 홈 화면으로 돌아가 코어가 실행 중인지 확인합니다. 클라이언트를 시작할 때 코어도 자동으로 실행되는 경우가 있고 “시작” 또는 연결 버튼을 눌러야 하는 경우도 있습니다. 설정 로드 실패 메시지가 표시되면 1단계로 돌아가 오류를 해결하세요. 트래픽 전달 스위치를 계속 바꾸지 마세요. “실행 중” 상태를 확인한 뒤 플랫폼에 맞는 전달 방식 하나를 켭니다. 처음 테스트할 때 시스템 프록시, TUN, DNS를 한꺼번에 변경하면 원인을 찾기 어려워집니다.

데스크톱: 먼저 시스템 프록시 테스트

설정이나 홈 화면에서 “시스템 프록시”를 찾아 켭니다. 클라이언트는 보통 시스템 HTTP·HTTPS 프록시를 로컬 수신 포트로 연결합니다. 다른 가이드의 포트 번호를 그대로 따라 하지 말고 현재 클라이언트에 표시된 설정을 기준으로 하세요. 설정을 켠 뒤 클라이언트를 실행 상태로 두고, 일반적으로 시스템 프록시를 따르는 브라우저에서 새 요청을 보냅니다. 브라우저 확장 프로그램이나 별도의 프록시 설정, 관리 정책이 시스템 설정을 덮어쓸 수 있으므로 이상이 있으면 각각 확인해야 합니다.

명령줄 도구가 시스템 프록시를 사용하지 않을 수도 있습니다. 브라우저에서는 접속되지만 터미널에서는 실패하더라도 노드가 고장 났다고 단정하지 마세요. 프록시 매개변수를 지원하는 도구에서 로컬 포트를 직접 지정하거나, 다음 단계에서 TUN을 사용할 수 있습니다. 환경 변수 설정 방법은 터미널 종류와 도구 구현에 따라 다릅니다. 브라우저와 터미널 연결 문제를 따로 점검하는 방법을 참고하세요. 먼저 브라우저 연결을 확인한 뒤 다른 앱으로 범위를 넓히면 원인을 더 쉽게 파악할 수 있습니다.

모바일: 시스템 VPN 권한 확인

모바일 클라이언트에서 연결 또는 시작 버튼을 누르면 처음 실행할 때 VPN 설정 추가를 요청하는 시스템 안내가 표시되는 경우가 많습니다. 요청을 보내는 앱을 확인하고 권한을 허용한 뒤 클라이언트로 돌아가 연결 상태를 확인하세요. 시스템에 VPN 아이콘이 표시되면 트래픽 전달 통로가 설정되었다는 뜻이지, 구독의 원격 서버에 반드시 연결된다는 뜻은 아닙니다. 이전에 다른 VPN을 사용했다면 연결을 먼저 끊으세요. 시스템에서 한 번에 하나의 통로만 유지되어 상태를 잘못 판단할 수 있습니다.

더 많은 트래픽을 전달해야 한다면 TUN 테스트

브라우저 연결은 확인했지만 게임이나 일부 명령줄 프로그램, 다른 앱이 클라이언트를 거치지 않을 때 TUN을 고려하세요. 먼저 시스템 프록시 상태를 기록하고 시스템 프록시를 끈 상태에서 별도로 비교합니다. 그런 다음 클라이언트 안내에 따라 서비스를 설치하거나 네트워크 권한을 허용한 뒤 TUN을 켜세요. 가상 네트워크 어댑터와 라우팅, DNS 전달 방식은 운영체제마다 다릅니다. 권한 오류가 나면 스위치를 반복해서 켰다 끄지 말고 클라이언트 안내에 따라 해결하세요.

TUN을 켠 뒤 클라이언트 로그에서 가상 네트워크 어댑터와 라우팅 설정이 완료되었는지 확인합니다. 네트워크가 바로 끊기면 먼저 TUN을 끄고 복구 여부를 확인한 뒤, 이미 검증한 시스템 프록시 경로로 돌아가세요. 다른 VPN이나 패킷 캡처 프로그램, 라우팅 설정을 계속 추가하지 마세요. 시스템 프록시와 TUN의 작동 계층 및 사용 범위는 트래픽 전달 방식 비교에서 확인할 수 있습니다. 이 페이지에서는 정상 작동하는 방식을 하나만 유지하면 됩니다.

STEP 04 / VERIFICATION

프록시와 규칙이 적용되는지 확인

클라이언트를 계속 실행하고 설정, 규칙 모드, 트래픽 전달 스위치가 의도한 상태인지 확인한 뒤 프록시를 통해 접속해야 하는 웹사이트를 엽니다. 새 탭에서 새 요청을 보내 이미 열린 페이지나 캐시된 내용을 연결 성공으로 착각하지 않도록 하세요. 페이지가 열리는 것은 첫 번째 확인 항목이지만 어떤 아웃바운드를 사용했는지는 증명하지 못합니다. 대상 사이트가 직접 연결도 지원할 수 있기 때문입니다.

클라이언트에서 “연결” 또는 “요청 기록” 페이지를 열고 브라우저에서 대상을 다시 방문해 해당 도메인을 찾습니다. 대상 주소, 적용된 규칙, 최종 정책 또는 노드 등 세 항목을 확인하세요. 기록에 직접 연결 규칙이 표시된다면 페이지가 열렸더라도 프록시가 적용되었다고 볼 수 없습니다. 정책 그룹을 통해 요청이 전달된 경우에는 최상위 그룹 이름만 보지 말고 최종 노드도 확인해야 합니다. 일부 클라이언트는 요청이 끝나면 연결 기록을 지웁니다. 기록 유지 기능을 켜거나 요청을 보낼 때 동시에 확인하세요.

신뢰할 수 있는 외부 IP 조회 서비스로 다시 확인하고 직접 연결 결과와 비교하세요. IP가 속한 지역은 참고 정보일 뿐이며 데이터베이스 반영이 늦을 수 있고 IPv4와 IPv6가 서로 다른 경로를 사용할 수도 있습니다. 지역 표시만으로 결론을 내리지 마세요. 새 요청이 클라이언트에 들어오고 예상한 프록시 정책이 적용되며 대상에 실제로 접속되고, 외부 IP 정보도 선택한 아웃바운드와 일치하는지 함께 확인하는 것이 가장 좋습니다.

마지막으로 설정상 직접 연결되어야 하는 대상에 접속해 예상 규칙이 적용되는지 확인합니다. 규칙 모드에서는 대상마다 외부 IP가 다르게 표시되는 것이 정상이며, 조회 결과를 모두 같게 만들기 위해 전역 모드를 계속 사용할 필요는 없습니다. 짧게 비교하려면 현재 상태를 기록하고 전역 모드로 바꾼 뒤 노드를 지정해 새 요청을 보내고 다시 규칙 모드로 복구하세요. 이미 연결된 장시간 연결은 기존 경로를 계속 사용할 수 있습니다.

확인이 끝나면 평소 방식대로 클라이언트를 종료하고 시스템 프록시가 복구되었는지 확인한 뒤 다시 실행해 간단한 접속 테스트를 반복합니다. 종료와 재시작 후에도 상태가 예상대로 유지되는지 확인할 수 있습니다. 데스크톱 클라이언트를 종료했는데도 시스템 프록시가 로컬 프록시 포트를 가리키고 있으면 브라우저가 인터넷에 연결되지 않을 수 있습니다. 이때는 노드를 계속 바꾸지 말고 시스템 프록시 설정을 먼저 복구하세요. 첫 연결을 확인한 뒤 시작 프로그램 등록과 구독 자동 업데이트를 설정해 검증되지 않은 상태가 오래 유지되지 않도록 하세요.

실패하면 연결 단계별로 점검

4단계에서 실패했다면 “설정 가져오기 → 코어 로드 → 노드 아웃바운드 → 트래픽 전달 → 규칙 및 DNS” 순서로 확인하세요. 한 번에 설정 하나만 바꾸고 같은 대상으로 다시 테스트하면 무작위로 스위치를 바꿔 일시적으로 연결하는 대신 문제가 발생한 단계를 찾을 수 있습니다.

  1. 설정 다운로드 실패: 기본 네트워크가 작동하는지, 구독이 유효한지, 가져온 주소가 설정용 링크인지 확인하세요. HTTP 상태 코드나 파싱 오류도 살펴보세요. 다운로드 결과가 로그인 페이지라면 서비스 제공업체에 문의해 올바른 링크를 다시 받으세요.
  2. 설정 로드 실패: 로그에서 YAML 파싱 오류, 정책 그룹 참조 오류 또는 외부 리소스 다운로드 오류가 있는지 확인하세요. 먼저 원본 구독을 다시 다운로드하고 오류 원인을 파악하기 전에 설정을 대량으로 수정하지 마세요.
  3. 노드 테스트 시간 초과: 같은 정책 그룹에서 다른 노드를 선택하고 동일한 대상으로 다시 테스트하세요. 모든 노드에서 실패한다면 구독 계정 상태와 현재 네트워크 제한을 확인하세요. 테스트에 성공했더라도 실제 접속 확인은 필요합니다.
  4. 브라우저 요청 기록 없음: 코어가 실행 중인지, 시스템 프록시나 VPN 전달이 켜져 있는지 확인하고 브라우저 프록시 확장 프로그램도 점검하세요. 먼저 요청이 클라이언트에 들어오는지 확인한 다음 규칙 설정을 살펴보세요.
  5. 기록은 있지만 연결 실패: 최종 아웃바운드와 구체적인 오류를 확인하세요. 도메인 이름을 해석하지 못한다면 DNS를 먼저 점검합니다. 연결 거부나 시간 초과가 발생하면 선택한 노드와 대상을 확인하세요. 로그 한 줄만 보고 DNS 설정 전체를 변경하지 마세요.

추가 문의가 필요하다면 운영체제와 클라이언트 이름, 시스템 프록시와 TUN 중 사용한 방식, 실패한 대상, 관련 오류 문구를 기록하세요. 구독 주소와 계정 정보는 가린 뒤 필요한 로그 일부만 제공하세요. 재현 가능한 작업 순서를 설명하면 전체 화면 캡처나 막연한 “인터넷이 안 돼요”라는 설명보다 원인을 파악하기 쉽습니다.

기본 연결이 확인되면 전체 플랫폼 설치 및 설정 가이드를 참고해 규칙 세트, DNS와 fake-ip, 서비스 권한 및 플랫폼별 문제를 살펴보세요. 이후 구독을 업데이트하거나 트래픽 전달 방식을 바꿀 때마다 4단계의 실제 요청 확인을 반복해 변경 사항이 예상대로 작동하는지 확인하세요.