작업 01 / 설정 메뉴
구독을 가져와 설정 적용하기
신뢰할 수 있는 서비스 제공업체에서 구독 URL을 받은 뒤, 해당 주소가 Clash 또는 mihomo용 설정 구독인지 확인하세요. 사용자 센터 주소나 결제 페이지, 단일 노드 공유 텍스트와 혼동하지 마세요. 구독 URL에는 계정을 식별하는 매개변수가 포함되는 경우가 많으므로 계정 정보처럼 안전하게 보관하고 공개 댓글, 스크린샷, 온라인 변환 사이트에 붙여 넣지 마세요. 클라이언트는 설정을 읽고 연결을 구성할 뿐이며, 클라이언트를 설치한다고 사용할 수 있는 원격 서버가 생기는 것은 아닙니다.
클라이언트를 열고 ‘설정’, ‘구독’ 또는 ‘Profiles’ 페이지로 이동해 ‘새로 만들기’, ‘구독 추가’ 또는 ‘URL에서 가져오기’를 찾습니다. 입력란에 전체 URL을 붙여 넣고 ‘일상 설정’처럼 알아보기 쉬운 이름을 지정하세요. 붙여 넣은 뒤 URL 앞뒤에 공백이나 줄바꿈, 메신저가 덧붙인 문장 부호가 없는지 확인합니다. 주소를 짧게 보이게 하려고 물음표 뒤의 매개변수를 삭제하지 마세요. 확인한 다음 ‘가져오기’, ‘다운로드’ 또는 ‘저장’을 눌러 첫 동기화가 끝날 때까지 기다립니다.
다운로드 후 해당 설정을 선택해야 합니다
설정 목록에 새 카드가 나타났다고 해서 바로 사용 중인 것은 아닙니다. 카드의 ‘사용’, ‘활성화’ 또는 선택 버튼을 눌러 현재 설정으로 표시되는지 확인하세요. 코어를 다시 불러오라는 안내가 나오면 지시에 따라 진행합니다. 다음으로 프록시 페이지에서 구독에 정의된 프록시 그룹이 표시되는지, 규칙 페이지에서 규칙 목록이나 로드 상태가 보이는지 확인하세요. 일부 설정은 규칙 집합이나 데이터 파일을 추가로 다운로드하므로 첫 로드에는 시간이 걸릴 수 있습니다. 진행 중에는 업데이트를 반복해서 누르지 마세요.
제공업체가 로컬 YAML 파일을 제공했다면 ‘파일에서 가져오기’를 사용해 해당 파일을 선택하세요. 파일 내용을 통째로 구독 URL 입력란에 넣지 마세요. 로컬 파일은 보통 원격 구독처럼 자동 업데이트되지 않지만, 원격 구독은 설정 페이지에서 직접 업데이트할 수 있습니다. 처음에는 한 번 수동으로 업데이트해 설정이 정상적으로 읽히는지 확인한 후 자동 업데이트 주기를 지정하는 것이 좋습니다. 구독을 업데이트하면 구독 파일을 직접 수정한 내용이 덮어써질 수 있습니다. 개인 설정은 클라이언트의 오버라이드 또는 병합 기능을 사용하세요. 처음 설정할 때는 이런 부분까지 다룰 필요가 없습니다.
가져오기 실패: 어느 단계에서 문제가 생겼는지 확인하기
다운로드 시간 초과가 표시되면 설정을 가져오지 못한 상태입니다. 기본 네트워크, URL 유효 기간, 서비스 제공업체의 별도 가져오기 방법 요구 여부를 먼저 확인하세요. YAML 파싱 오류, 필드 누락, 알 수 없는 프로토콜이 표시된다면 내용은 받았지만 형식이나 코어 호환성에 문제가 있을 수 있습니다. 브라우저에서 주소가 열린다고 해서 설정이 반환된다는 뜻은 아닙니다. 로그인 페이지나 오류 안내가 표시될 수도 있습니다. Base64 노드 목록과 Clash YAML은 서로 다른 설정 형식이므로 모든 구독을 그대로 사용할 수 있다고 가정하지 마세요.
형식 문제가 있으면 낯선 변환 서비스에 전체 URL을 보내기보다, 먼저 제공업체에 현재 클라이언트에 맞는 구독을 요청하세요. 형식 차이는 구독 URL 가져오기와 형식 안내에서 확인할 수 있습니다. 이 단계의 완료 조건은 명확합니다. 현재 설정이 선택되어 있고, 프록시 그룹이 표시되며, 파싱 오류가 계속 발생하지 않아야 합니다. 조건을 충족하면 실행 모드를 선택하세요.
작업 02 / 출구 선택
규칙 모드와 프록시 그룹 선택
설정을 불러온 뒤 클라이언트 홈, 대시보드 또는 프록시 설정에서 실행 모드를 찾으세요. 처음에는 보통 ‘규칙’ 또는 ‘Rule’을 선택합니다. 규칙 모드에서는 현재 설정의 도메인, 주소 등의 조건에 따라 연결 경로를 정합니다. 일부 요청은 직접 연결되고, 일부는 프록시 그룹을 사용하며, 일부는 거부될 수 있습니다. 따라서 클라이언트를 켰다고 모든 웹사이트가 하나의 원격 노드를 통하는 것은 아닙니다. 이것이 규칙 기반 분기의 목적입니다.
같은 위치에서 ‘전역’과 ‘직접 연결’ 모드도 선택할 수 있습니다. 전역 모드는 코어에 들어오는 요청을 전역 출구 선택에 따라 처리하므로 임시 비교나 문제 해결에 쓸 수 있지만, 설정을 확인하지 않은 채 계속 사용하는 것은 권장하지 않습니다. 직접 연결 모드는 보통 코어에 들어온 요청을 대상에 바로 연결합니다. 실행 모드는 코어가 이미 받은 요청을 처리하는 방법을 정할 뿐, 모든 앱의 트래픽을 자동으로 코어에 전달하지는 않습니다. ‘규칙 모드 선택’과 ‘시스템 프록시 활성화’는 별개의 설정입니다.
모드를 선택한 뒤 규칙에서 실제 사용하는 그룹 확인하기
‘프록시’ 또는 ‘Proxies’ 페이지에서 현재 설정이 일반적인 접속에 사용하는 선택 그룹을 찾으세요. 구독마다 ‘노드 선택’, ‘프록시’ 등 이름이 다를 수 있으므로 특정 그룹 이름을 전제로 하지 않습니다. 그룹을 열어 수동 선택 그룹이라면 사용 가능한 노드를 선택하세요. 자동 선택 그룹이 있다면 해당 그룹을 선택해 설정된 상태 점검을 수행하게 할 수 있습니다. 선택 후 체크 표시, 테두리 또는 현재 값이 바뀌는지 확인하고, 페이지를 나갔다가 다시 들어와 선택이 유지되는지도 살펴보세요.
구독에는 서비스별 전용 그룹이 추가로 있을 수 있으며, 각 그룹을 따로 선택하거나 기본 선택 그룹을 계속 참조하게 할 수 있습니다. 이름이 눈에 띄는 그룹 하나만 바꿨다고 모든 규칙이 그 그룹을 사용하는 것은 아닙니다. 다음 단계에서 실제 요청이 어떤 출구 경로를 탔는지 확인해야 합니다. 처음에는 모든 그룹을 동시에 조정하지 말고 구독 기본 구성을 유지하세요. 주 출구가 직접 연결이나 거부로 잘못 선택되지 않았는지 확인한 뒤 실제 요청으로 경로를 점검합니다.
클라이언트에 ‘연결 테스트’, ‘상태 점검’ 또는 ‘속도 측정’ 버튼이 있다면 한 번 실행해 테스트 대상에 도달할 수 있는지 확인할 수 있습니다. 테스트 결과는 해당 노드에서 테스트 대상까지의 경로가 그 시점에 사용 가능했다는 뜻일 뿐, 모든 웹사이트에 접속할 수 있거나 실제 다운로드 속도가 빠르다는 의미는 아닙니다. 한 번의 시간 초과는 테스트 주소 때문일 수도 있습니다. 예상에 맞는 노드 하나를 시험해 보고 목록 전체를 연속해서 반복 테스트하지 마세요.
기본 규칙을 유지해 첫 설정의 변수를 줄이세요
이 단계에서는 인터넷에서 찾은 긴 규칙을 구독에 그대로 덮어쓰지 않는 것이 좋습니다. 규칙에서 참조하는 그룹 이름은 설정과 일치해야 하며, 규칙 순서에 따라서도 출구가 달라집니다. YAML 형식이 올바르더라도 이름이 일치하지 않으면 로드가 실패하거나 잘못된 경로로 연결될 수 있습니다. ‘프록시 그룹’, ‘규칙 모드’, ‘노드’의 차이를 알고 싶다면 용어 빠른 안내를, 프로토콜 지원, 코어 계열 및 설정 호환성은 기술 참고 자료를 확인하세요. 이 페이지에서는 우선 안내된 순서대로 설정을 진행하면 됩니다.
다음 단계로 넘어가기 전에 모드가 규칙으로 표시되고, 주 출구 그룹이 선택되어 있으며, 설정 전환으로 코어 오류가 발생하지 않았는지 확인하세요. 현재 선택한 그룹과 노드 이름을 기억해 두면 시스템 트래픽을 연결한 뒤 연결 목록의 실제 출구와 비교할 수 있습니다.
작업 03 / 트래픽 연결
코어를 시작하고 연결 켜기
설정과 출구를 정한 뒤 클라이언트 홈에서 코어 상태를 확인하세요. 데스크톱 클라이언트는 실행과 함께 코어가 시작되기도 하고, ‘시작’ 또는 ‘연결’을 눌러야 하는 경우도 있습니다. 실행 상태가 된 것을 확인한 다음 ‘시스템 프록시’를 켜세요. 시스템 프록시는 운영체제의 프록시 설정을 따르는 앱의 요청을 로컬 수신 포트로 전달합니다. 기기의 모든 네트워크 트래픽을 가로채는 기능은 아니므로 일부 게임, 명령줄 프로그램, 자체 네트워크 설정을 사용하는 앱은 이 경로를 사용하지 않을 수 있습니다.
클라이언트에서 ‘시스템 프록시’와 ‘TUN’을 모두 제공한다면 처음 확인할 때는 점검하기 쉬운 시스템 프록시부터 사용하는 것이 좋습니다. 두 기능을 한꺼번에 켜고 DNS와 라우팅까지 동시에 조정하지 마세요. TUN은 가상 네트워크 인터페이스로 트래픽을 연결하며, 보통 서비스 구성 요소나 더 높은 권한이 필요합니다. 브라우저 요청이 규칙에 따라 제대로 분기되는 것을 확인한 뒤 필요한 앱이 있는지 검토해 활성화하세요. 플랫폼마다 TUN 지원 여부와 설정 요구 사항이 다릅니다.
데스크톱: 먼저 실행한 뒤 시스템 프록시 켜기
Windows, macOS 또는 Linux 데스크톱 클라이언트에서 ‘설정’, ‘네트워크’ 또는 트레이 메뉴로 이동해 시스템 프록시를 켜고, 홈 화면으로 돌아와 스위치가 계속 켜져 있는지 확인하세요. 일부 Linux 데스크톱 환경에서는 앱 자체가 데스크톱 프록시 설정을 따라야 하므로 스위치가 켜졌다는 사실만으로는 충분하지 않습니다. 처음에는 다른 프록시 도구를 꺼 두어 시스템 설정 충돌을 방지하세요. 브라우저에 별도 프록시 확장 프로그램이 있다면 시스템 설정을 사용하도록 잠시 되돌려야 합니다. 그렇지 않으면 확장 프로그램의 출구를 테스트하게 될 수 있습니다.
권한 안내가 표시되면 어떤 작업에 필요한 권한인지 먼저 확인하세요. 시스템 프록시 전환, 서비스 구성 요소 설치, 가상 인터페이스 활성화는 서로 다른 권한이 필요합니다. 해당 설정을 직접 실행하는 중이고 안내가 사용 중인 클라이언트에서 온 것이 맞을 때만 진행하세요. 일반 웹페이지가 열리지 않는다는 이유로 모든 프로그램을 관리자 권한으로 실행하지 마세요. 화면에 서비스가 설치되지 않았다고 명확히 표시되면 클라이언트 안내에 따라 필요한 구성 요소를 설치한 다음 원래 단계로 돌아갑니다.
로그에 수신 주소가 사용 중이라고 표시되면 같은 포트를 사용할 수 있는 다른 프록시 프로그램을 먼저 중지한 뒤 다시 시작하세요. 일반적인 mixed-port는 HTTP와 SOCKS가 공유하는 수신 포트지만, 실제 포트는 현재 설정과 클라이언트의 값에 따릅니다. 포트를 바꿔야 한다면 클라이언트에 표시된 수신 포트와 앱에 수동으로 입력한 프록시 포트가 일치해야 합니다. 안내서에 나온 포트 번호를 기기에서 반드시 써야 하는 고정값으로 여기지 마세요.
모바일: 시스템 VPN 권한과 연결 상태 확인
Android 또는 iOS 클라이언트 홈에서 ‘연결’이나 시작 버튼을 누르세요. 처음에는 시스템 VPN 설정 또는 연결 요청이 표시되는 경우가 많으니 앱 이름을 확인한 뒤 허용합니다. 연결이 완료되면 클라이언트의 상태가 바뀌고 시스템에도 VPN 상태가 표시되어야 합니다. 여기서 VPN은 시스템 네트워크 인터페이스를 통해 트래픽을 연결한다는 뜻이지, 모든 요청이 반드시 원격 프록시를 통한다는 뜻은 아닙니다. 규칙에 따라 직접 연결할 항목과 선택한 출구를 사용할 항목이 결정됩니다.
시스템에서 다른 VPN 연결이 있다고 알리면 기존 연결을 먼저 끊고 현재 클라이언트를 테스트하세요. 연결에 성공하면 다음 단계의 확인을 마칠 때까지 클라이언트를 전면에 둔 뒤, 백그라운드로 전환해도 안정적인지 살펴봅니다. Android의 배터리 절약 제한은 백그라운드 실행에 영향을 줄 수 있지만 기본 연결을 확인하기도 전에 배터리 설정을 여기저기 바꾸지는 마세요. 백그라운드 연결 끊김, 권한 요청 반복, 포트 충돌의 자세한 해결 방법은 자주 묻는 질문을 참고하세요. 현재 표시된 안내부터 확인하고 관련 없는 설정은 바꾸지 마세요.
작업 04 / 실제 요청
규칙과 출구를 확인해 작동 여부 검증하기
연결 버튼이 켜졌다는 것은 구성 요소가 시작됐다는 뜻일 뿐입니다. 제대로 작동하는지 확인하려면 요청이 코어에 들어왔는지, 최종적으로 어떤 출구가 선택됐는지 살펴봐야 합니다. 먼저 브라우저에서 새 탭을 열어 정상적으로 열리는 것을 아는 웹사이트에 접속하고 기본 네트워크가 작동하는지 확인하세요. 그런 다음 현재 설정에서 프록시 그룹을 사용해야 하는 대상에 접속합니다. 이전 탭을 새로고침하며 확인하는 것만으로는 부족합니다. 페이지가 캐시에서 열렸거나 기존 연결이 방금 바꾼 출구를 바로 사용하지 않을 수 있습니다.
클라이언트의 ‘연결’, ‘Connections’ 또는 요청 로그 페이지로 돌아가 방금 접속한 도메인을 찾으세요. 클라이언트마다 표시되는 항목은 다르지만 대상, 일치한 규칙, 아웃바운드 경로를 확인하면 됩니다. 대상은 이번 요청과 일치해야 하고, 일치한 규칙은 해당 경로를 선택한 이유를 보여주며, 아웃바운드 경로에는 예상한 프록시 그룹이나 노드가 표시되어야 합니다. 규칙에 따라 직접 연결되어 DIRECT로 표시되는 것은 정상입니다. 요청 하나가 노드를 거치지 않았다고 클라이언트가 작동하지 않는다고 판단하지 마세요.
직접 연결과 프록시 경로를 각각 확인하기
예상 출구가 서로 다른 대상 두 곳을 선택해 각각 새 요청을 보낸 뒤 연결 목록과 비교하세요. 두 요청 모두 설정에 맞게 처리되면 시스템 연결과 규칙 분기의 기본 경로가 작동하는 것입니다. IP 확인 사이트는 참고용으로 사용할 수 있지만, 해당 사이트에 접속할 때 사용한 출구만 보여줄 뿐 다른 앱이나 모든 도메인이 같은 경로를 사용한다는 점까지 증명하지는 않습니다. 규칙 작동 여부는 주소가 바뀌었는지만 보지 말고 해당 연결의 매칭 결과를 기준으로 판단하세요.
연결 목록에 브라우저 요청이 전혀 없다면 먼저 시스템 프록시가 실제로 켜져 있는지, 브라우저가 별도 확장 프로그램이나 수동 프록시 설정을 사용하고 있지는 않은지 확인하세요. 요청이 현재 코어에 들어오지 않았으므로 노드를 바꿔도 연결 경로 문제는 해결되지 않습니다. 특정 앱의 요청만 기록되지 않는다면 해당 앱이 시스템 프록시를 지원하는지 확인하세요. 더 많은 트래픽을 연결해야 한다면 TUN을 검토하세요. 앱의 트래픽을 강제로 연결하려고 규칙 모드를 전역 모드로 바꾸지는 마세요.
요청은 목록에 있지만 출구가 예상과 다르면 두 번째 단계로 돌아가 현재 모드, 일치한 규칙, 프록시 그룹 선택을 확인하세요. 출구는 맞는데 연결이 실패한다면 노드의 사용 가능 여부, 서비스 상태, 로그의 구체적인 오류를 살펴봅니다. 이름 해석 오류는 보통 도메인 확인 경로를 가리킵니다. 연결 시간 초과는 대상과 노드를 함께 고려해야 하며, ‘시간 초과’라는 문구만으로 DNS 문제라고 단정할 수 없습니다. 한 번에 변수 하나만 바꾸고 새 요청을 보내 결과를 확인해야 어떤 조정이 효과가 있었는지 알 수 있습니다.
한 번 재연결한 뒤 첫 설정 마무리하기
기본 접속이 정상이라면 연결을 한 번 끊었다가 다시 연결하고 새 웹 요청을 보내 설정과 프록시 그룹 선택이 유지되는지 확인하세요. 데스크톱에서는 클라이언트를 정상적으로 종료한 뒤 시스템 프록시 설정이 복원되는지도 확인할 수 있습니다. 종료 후 웹페이지에 문제가 생기면 남아 있는 시스템 프록시 설정을 먼저 끄고 클라이언트를 다시 시작해 처리하세요. 설정을 바로 삭제하면 정상적으로 선택된 출구와 구독 정보까지 사라져 복구 작업이 더 늘어날 수 있습니다.
마지막으로 설정 페이지에서 구독을 한 번 수동 업데이트하고, 업데이트 후에도 예상한 설정이 사용되며 주요 프록시 그룹에 유효한 선택이 남아 있는지 확인하세요. 시작 프로그램 등록, 백그라운드 실행, 자동 업데이트는 기본 연결을 확인한 뒤 설정하면 됩니다. 처음 구독을 가져올 때 한꺼번에 처리할 필요는 없습니다. 네 가지 작업 결과가 모두 일치하면 첫 설정이 완료된 것입니다. 설정이 정상적으로 로드되고, 규칙 모드가 선택되며, 시스템 트래픽이 연결되고, 실제 요청이 규칙과 출구에 맞게 처리되어야 합니다.
가끔 접속이 되지 않는다면 먼저 증상별 문제 해결 안내에서 해당 상황을 찾으세요. 프로토콜 차이, 모바일 환경에서의 기능 선택, mihomo 설정 호환성을 알아보려면 프로토콜 및 코어 기술 참고 자료를 확인하세요. 작동하는 기본 설정은 유지하고 기능을 하나씩 추가하는 편이 설정 페이지를 한꺼번에 바꾸는 것보다 관리하기 쉽습니다.