시작 전 확인: 설정 출처와 네트워크
먼저 클라이언트를 종료한 상태에서도 원래 접속할 수 있던 웹사이트에 연결되는지 확인하고, 공용 네트워크의 로그인 인증도 완료하세요. 이렇게 하면 기기 자체의 네트워크 문제와 프록시 설정 문제를 구분할 수 있습니다. 처음 설정할 때는 다른 프록시 클라이언트와 VPN을 일시 중지하고 이 가이드 페이지를 열어 두세요. 원격 데스크톱에서 라우팅을 변경한다면 트래픽 전달을 켠 뒤에도 다시 연결할 방법이 있는지 먼저 확인하세요. 원격 접속이 끊길 수 있습니다.
신뢰할 수 있는 출처에서 제공한 Clash 또는 mihomo 호환 구독 URL이나 서비스 제공자가 안내한 YAML 설정 파일을 준비하세요. 클라이언트는 설정을 읽고 연결을 처리할 뿐, 그 자체로 사용할 수 있는 프록시 서비스를 제공하지는 않습니다. 노드 주소 목록, 웹 계정 주소 또는 다른 형식의 구독은 바로 가져오지 못할 수 있습니다. 서비스 안내에서 지원 형식을 확인하고, 계정 비밀번호를 설정 이름 입력란에 넣지 마세요.
구독 링크에는 계정을 식별하는 인증 정보가 포함되는 경우가 많으므로 비밀번호처럼 안전하게 보관하세요. 복사할 때 앞뒤에 공백이나 줄바꿈, 메신저가 덧붙인 문구가 들어가지 않았는지 확인하세요. 출처를 알 수 없는 온라인 변환 도구에 붙여 넣거나 전체 주소가 보이도록 공개 스크린샷을 찍지 마세요. 준비가 끝나면 클라이언트의 메인 창을 열고 설정 관리 메뉴로 이동하세요.
1단계: 구독 가져오기 및 활성화
‘구독’, ‘설정’ 또는 ‘Profiles’ 페이지로 이동해 ‘새로 만들기’, ‘추가’, ‘가져오기’ 또는 더하기 버튼을 찾으세요. URL 가져오기를 선택하고 구독 주소 전체를 입력란에 붙여 넣으세요. 구분하기 쉽도록 이름을 지정해도 됩니다. 주소가 올바른지 확인한 뒤 가져오기 또는 저장을 누르고 다운로드와 파싱이 완료될 때까지 기다리세요. 이 과정에서 현재 네트워크가 구독 서버에 접속할 수 있어야 합니다.
로컬 파일을 받은 경우 ‘파일에서 가져오기’를 선택해 해당 .yaml 또는 .yml 파일을 불러오세요. 다운로드한 웹페이지의 파일 이름만 YAML로 바꾸면 안 됩니다. 확장자가 올바르더라도 파일 내용의 형식이 올바르다는 뜻은 아닙니다. 파일 출처에서 호환되는 코어를 확인하세요. 클라이언트에 파싱 오류가 표시되면 오류에 나온 줄 번호와 필드 이름을 기록한 뒤 설정 제공자에게 문의하세요. 오류가 난 필드를 계속 삭제해 억지로 불러오지는 마세요.
가져오기에 성공하면 설정 목록에 새 항목이 추가되고 업데이트 시간, 이름, 출처 등이 표시됩니다. 클라이언트에 따라 새 항목을 자동으로 활성화하거나, 설정 카드를 클릭하거나 메뉴에서 ‘사용’ 또는 ‘활성화’를 선택해야 할 수 있습니다. 현재 선택된 항목이 방금 가져온 설정인지 확인하세요. ‘다운로드 성공’ 메시지만으로는 코어가 해당 설정을 사용하고 있다고 볼 수 없습니다.
그런 다음 ‘프록시’ 페이지를 열어 프록시 그룹과 그룹 내 노드가 표시되는지 확인하세요. 그룹 이름은 설정 작성자가 정하므로 ‘노드 선택’, ‘프록시’ 등 다양한 이름으로 표시될 수 있습니다. 가이드와 이름이 정확히 같지 않아도 됩니다. 목록이 비어 있으면 설정 페이지로 돌아가 올바른 항목을 활성화했는지 확인하고 로드 실패 메시지가 있는지 살펴보세요. 먼저 설정 로드 문제를 해결하고, 이 단계에서는 전역 모드를 켜거나 TUN을 반복해서 전환하지 마세요.
구독 업데이트와 설정 활성화는 별개의 작업입니다. 나중에 업데이트를 누르면 클라이언트가 원격 설정을 다시 가져옵니다. 서비스 제공자가 노드를 변경한 뒤에도 로컬 설정에는 이전에 수동으로 선택한 노드가 남아 있을 수 있습니다. 업데이트가 끝나면 프록시 그룹으로 돌아가 선택한 항목이 유효한지 확인하세요. 원격 설정 내용을 직접 수정하면 업데이트 후 덮어써질 수도 있습니다. 사용자 지정 규칙을 유지하려면 클라이언트가 지원하는 오버라이드 기능을 사용하세요. 구체적인 방법은 기본 연결 확인을 마친 뒤 살펴보면 됩니다.
완료 조건은 설정 항목이 활성화되어 있고 프록시 페이지에 선택할 수 있는 그룹이 표시되는 것입니다. 두 조건을 모두 충족하면 모드를 선택하세요. 구독, 설정 파일, 프록시 그룹의 관계는 용어집에서 확인할 수 있습니다. 처음 연결할 때 YAML의 모든 필드를 알 필요는 없습니다.
2단계: 규칙 모드와 노드 선택
‘개요’, ‘프록시’ 또는 설정 페이지에서 모드 전환 메뉴를 찾으세요. 처음에는 ‘규칙’ 또는 ‘Rule’을 선택하는 것이 좋습니다. 코어는 현재 설정의 규칙에 따라 연결을 직접 연결하거나 프록시를 거치게 하거나 차단합니다. 실제 동작은 설정 내용에 따라 달라지며, 클라이언트가 각 웹사이트에 적합한 경로를 미리 알고 있는 것은 아닙니다. 적절한 규칙이 설정에 없으면 기본 규칙이 적용됩니다.
규칙 모드로 전환한 뒤 설정의 기본 프록시 그룹을 여세요. 그룹에 개별 노드가 표시되면 현재 서비스에서 사용할 수 있다고 확인된 노드를 선택하세요. ‘자동 선택’, ‘장애 조치’ 같은 그룹이 있으면 해당 그룹을 선택해도 됩니다. 설정에 포함된 테스트와 전환 로직에 따라 실제 출구가 결정됩니다. 그룹 이름에 지역명이 들어 있어도 실제 출구 위치가 그 지역이라고 단정할 수 없습니다. 마지막 단계에서 직접 확인하세요.
클라이언트에 ‘지연 시간 테스트’나 ‘연결 테스트’가 있으면 초기 점검용으로 한 번 실행해도 됩니다. 테스트 결과가 표시되면 해당 조건에서 테스트 대상이 응답했다는 뜻이고, 시간 초과가 발생하면 노드나 네트워크를 계속 확인해야 합니다. 테스트 수치는 다운로드 속도가 아니며 모든 웹사이트에 접속할 수 있다는 보장도 아닙니다. 서비스에 따라 출구나 프로토콜을 제한할 수 있으므로 노드 테스트에 성공해도 실제 대상 페이지를 열어 확인하세요.
‘전역’ 모드는 코어로 들어온 연결을 전역 정책에 따라 처리합니다. 분할 규칙이 문제의 원인인지 짧은 시간 동안 비교할 때 유용합니다. ‘직접 연결’ 모드는 일반적으로 코어로 들어온 연결이 대상에 바로 접속하도록 합니다. 여기서 모드는 코어가 연결을 어떻게 처리할지 나타내며, 연결을 어떻게 포착할지는 설명하지 않습니다. 전역 모드를 선택하더라도 시스템 프록시나 다른 트래픽 전달 방식을 켜지 않은 앱은 코어를 완전히 우회할 수 있습니다.
문제 확인을 위해 전역 모드를 사용할 때는 전역 정책에서 DIRECT가 아닌 특정 노드를 선택했는지 함께 확인하세요. 비교가 끝나면 규칙 모드로 돌아가 원래 직접 연결해야 하는 서비스까지 프록시를 거치지 않도록 하세요. 처음 설정하는 단계에서는 규칙을 직접 재정렬하거나 DNS를 수정하지 않는 것이 좋습니다. 먼저 가져온 설정의 기본 동작으로 확인해야 동시에 바뀌는 변수를 줄일 수 있습니다.
완료 조건은 모드가 규칙으로 표시되고 실제 사용할 프록시 그룹에서 노드 또는 정상 작동하는 자동 선택 그룹이 선택된 것입니다. 이 시점에는 클라이언트가 연결을 처리할 설정이 준비됐지만 브라우저 트래픽은 아직 코어에 들어오지 않았을 수 있습니다. 다음 단계에서 트래픽 전달을 켜세요. 프록시 페이지에 머무르는 것만으로는 충분하지 않습니다.
3단계: 시스템 프록시 또는 TUN 활성화
먼저 개요 페이지로 돌아가 코어가 실행 중인지 확인하세요. 클라이언트에 별도의 ‘시작’, ‘연결’ 버튼이나 코어 스위치가 있다면 트래픽 전달 설정 전에 실행하세요. 설정 파싱에 실패해 코어가 실행되지 않는 상태에서 시스템 프록시를 켜면 브라우저가 요청을 받을 프로그램이 없는 로컬 포트를 바라보게 되어 모든 페이지가 열리지 않을 수 있습니다. 따라서 프록시 스위치보다 코어 실행 여부를 먼저 확인해야 합니다.
데스크톱: 시스템 프록시로 브라우저부터 확인
Windows 또는 macOS 데스크톱 클라이언트에서 ‘시스템 프록시’ 스위치를 찾아 켜세요. 보통 운영체제의 프록시 설정이 로컬 코어를 가리키도록 변경되며, 시스템 프록시 설정을 따르는 브라우저와 앱은 해당 경로로 연결됩니다. 스위치를 켠 뒤 브라우저에서 새 탭을 열거나, 설정 변경 전부터 실행 중이던 앱을 재시작해 이후 연결에 새 설정이 적용되도록 하세요. 기존 장기 연결은 즉시 전환되지 않을 수 있습니다.
앱에서 별도 프록시를 설정했다면 시스템 설정이 적용되지 않을 수 있고, 시스템 프록시를 사용하지 않는 앱도 있습니다. 그렇다고 노드가 잘못됐다고 바로 판단하지 마세요. Linux 데스크톱 환경마다 시스템 프록시 지원 방식도 다릅니다. 일부 클라이언트는 현재 데스크톱 세션에만 프록시를 설정하며 터미널 프로그램은 별도 설정이 필요할 수 있습니다. 먼저 시스템 프록시를 따르는 브라우저에서 정상 연결을 확인한 뒤 다른 앱을 점검하세요.
모바일: 시스템 VPN 연결 승인
Android 또는 iOS 클라이언트에서 설정과 노드를 선택한 뒤 연결을 누르세요. 시스템에 VPN 설정 추가 또는 VPN 연결 승인 창이 표시될 수 있습니다. 요청이 현재 클라이언트에서 나온 것인지 확인한 뒤 안내에 따라 승인하세요. 기기에 따라 잠금을 해제하거나 기기 암호를 입력해야 할 수 있습니다. 연결이 설정되면 시스템 설정이나 상태 표시 영역에 VPN 상태가 표시되는 경우가 많지만 아이콘은 운영체제 버전에 따라 다릅니다.
여기서 VPN 인터페이스는 클라이언트가 기기 트래픽을 전달하기 위한 시스템 기능을 뜻합니다. 연결했다고 해서 설정의 분할 규칙을 우회한다는 의미는 아닙니다. 연결 후에도 실제 접속 결과와 규칙 적용 여부를 확인해야 합니다. 다른 VPN이 실행 중이면 먼저 연결을 끊고 테스트하세요. 업무용 기기의 관리 정책이 VPN 설정을 제한할 수도 있습니다. 시스템에서 거부되면 기기 권한을 먼저 확인하고 같은 구독을 반복해서 가져오지 마세요.
TUN: 필요한 경우에만 활성화
브라우저는 정상적으로 연결되지만 특정 앱의 연결 기록이 없다면 TUN 모드를 고려하세요. ‘TUN’, ‘가상 네트워크 어댑터’ 또는 트래픽 전달 강화 메뉴를 찾아 클라이언트 안내에 따라 서비스를 설치하고 관리자 권한을 부여하거나 네트워크 확장을 승인하세요. TUN은 라우팅 계층에서 조건에 맞는 트래픽을 전달할 수 있지만, 실제 범위는 라우팅, 제외 항목, DNS 설정에 따라 달라집니다. 모든 연결이 반드시 프록시를 거친다고 단정할 수는 없습니다.
처음 확인할 때는 시스템 프록시를 끄고 TUN만 단독으로 테스트하면 어떤 전달 경로가 작동하는지 구분하기 쉽습니다. 이는 문제를 확인하기 위한 방법이며 모든 클라이언트에서 두 기능을 동시에 켤 수 없는 것은 아닙니다. TUN을 켠 뒤 로컬 네트워크, 프린터 또는 다른 VPN에 문제가 생기면 먼저 TUN을 꺼서 원래 상태로 되돌리세요. 권한, 가상 네트워크 어댑터, 라우팅 충돌에 관한 자세한 내용은 플랫폼별 전체 플랫폼 설치 및 설정 가이드를 확인하세요.
완료 조건은 코어가 실행 중이고 선택한 트래픽 전달 방식이 켜져 있으며, 시스템에서 처리 대기 중인 권한 요청이 없는 것입니다. 클라이언트에 ‘연결됨’이라고 표시되어도 특정 웹사이트가 정상적으로 열린다는 뜻은 아닙니다. 현재 설정을 유지한 채 마지막으로 실제 연결을 확인하세요.
4단계: 접속 및 규칙 적용 확인
먼저 평소 직접 연결할 수 있는 웹사이트를 열어 기본 네트워크가 정상인지 확인하세요. 그런 다음 새 탭에서 현재 설정상 프록시를 사용해야 하는 웹사이트에 접속해 제목만 보이는 것이 아니라 페이지 전체가 로드되는지 확인하세요. 캐시된 페이지 하나만으로 판단하지 마세요. 필요하면 새로고침하거나 새 브라우저 창을 열고, 그때 클라이언트에 해당 연결이 새로 표시되는지 살펴보세요.
클라이언트에서 ‘연결’, ‘Connections’ 또는 실시간 로그 페이지를 열고 방금 방문한 도메인으로 필터링하세요. 연결 정보에는 대상 도메인이나 IP, 적용된 규칙, 사용한 프록시 그룹과 최종 노드가 표시되는 경우가 많습니다. 항목은 클라이언트마다 다릅니다. 트래픽이 코어에 들어왔고 프록시 경로가 예상과 일치하는지 확인하는 것이 핵심입니다. DIRECT가 표시되어도 반드시 오류인 것은 아닙니다. 해당 대상이 원래 직접 연결되어야 하는지 먼저 확인하세요.
연결 정보에서 프록시 정책이 적용된 것을 확인했다면 신뢰할 수 있는 출구 IP 조회 페이지를 이용해 비교할 수도 있습니다. 조회 결과는 해당 요청의 출구를 나타낼 뿐, 기기의 모든 앱이 같은 출구를 사용한다는 뜻은 아닙니다. DNS 처리가 예상대로라는 점도 단독으로 증명하지 못합니다. 설정에 따라 조회 사이트가 직접 연결될 수 있으므로 지역 표시만 보고 성공 여부를 판단하지 말고 해당 도메인의 규칙 기록과 함께 확인하세요.
문제가 생기면 연결 경로를 따라 점검하기
클라이언트에 대상 연결이 표시되지 않으면 먼저 시스템 프록시나 TUN이 실제로 켜져 있는지 확인하세요. 앱에서 별도 프록시를 사용하지 않는지, 이전 연결을 계속 재사용하고 있지는 않은지도 살펴보세요. 대상 앱을 종료했다가 다시 열고 테스트하세요. 트래픽이 코어에 들어오지 않는 상태라면 노드를 바꿔도 해결되지 않을 수 있습니다. 먼저 트래픽 전달 경로를 확인하세요.
연결 기록은 있지만 예상과 다른 정책이 적용됐다면 현재 설정이 올바른지, 프록시 그룹이 원하는 노드를 가리키는지 확인하세요. 규칙은 순서대로 적용되므로 앞쪽 규칙이 뒤쪽 규칙보다 먼저 일치할 수 있습니다. 잠시 전역 모드로 비교해 볼 수 있습니다. 전역 모드에서는 접속되지만 규칙 모드에서는 안 된다면 규칙이나 규칙과 연관된 DNS 동작을 더 확인해야 합니다. 다만 이 결과만으로 어떤 규칙이 잘못됐다고 단정할 수는 없습니다.
예상한 노드를 사용 중인데도 연결 시간이 초과되면 먼저 사용 가능한 것으로 확인된 다른 노드로 바꾸고, 서비스 이용 기간이 만료됐거나 사용 제한이 있는지 확인하세요. 도메인 이름 해석 오류가 발생하면 오류 내용을 기록하고 기본 네트워크와 설정의 DNS 서버에 연결할 수 있는지 확인하세요. 노드 변경, DNS 수정, 클라이언트 재설치, TUN 활성화를 한꺼번에 하지 마세요. 한 번에 하나만 바꾼 뒤 같은 접속 테스트를 반복해야 결과를 비교할 수 있습니다.
문제 해결에 필요한 정보를 전달할 때는 클라이언트 이름, 운영체제, 트래픽 전달 방식, 대상 오류, 발생 단계만 기록하세요. 스크린샷을 공유하기 전에 전체 구독 URL, 노드 비밀번호, 계정 정보, 로컬 제어 인터페이스 인증 정보를 가리세요. 로그에도 방문 도메인이나 기기 경로가 포함될 수 있으니 공유 전에 확인해야 합니다. 전문 용어가 낯설다면 용어집에서 DNS, fake-ip, 프록시 그룹, TUN의 설명을 찾아보세요.
설정 완료 후 유지 및 종료
직접 연결해야 하는 대상과 프록시를 사용해야 하는 대상이 모두 정상적으로 열리고 연결 기록도 예상과 일치하면 첫 설정이 완료된 것입니다. 현재 활성화된 설정, 모드, 트래픽 전달 방식을 기록해 두면 나중에 업데이트하거나 설정을 변경한 뒤에도 정상 작동 상태로 돌아가기 쉽습니다. 구독 자동 업데이트, 시작 시 자동 실행, 세부 앱별 분할 설정이 필요하다면 그다음에 전체 플랫폼 가이드를 살펴보세요. 처음 연결할 때 모든 기능을 켤 필요는 없습니다.
더 이상 사용하지 않을 때는 클라이언트에서 시스템 프록시를 끄거나 VPN 연결을 해제하고 TUN을 끈 뒤 프로그램을 종료하세요. 정상적으로 종료하면 관련 설정이 보통 복구되지만 프로그램이 비정상적으로 종료되면 시스템 프록시 설정이 남을 수 있습니다. 종료 후 브라우저에 연결 문제가 생기면 운영체제의 네트워크 설정에서 수동 프록시가 여전히 로컬 주소를 가리키는지 먼저 확인하세요. TUN을 사용했다면 클라이언트 서비스와 가상 네트워크 어댑터가 예상대로 중지됐는지도 살펴보세요. 기본 네트워크가 복구된 뒤 다시 연결할지 결정하세요.