시작 전: 클라이언트 설치 및 기존 설정 보존
먼저 클라이언트 다운로드 페이지에서 기기의 운영체제와 프로세서 아키텍처에 맞는 설치 파일을 선택해 설치한 뒤 메인 화면을 엽니다. 클라이언트는 설정 관리, 화면 구성, 시스템 연동을 담당하고 코어는 프록시 연결, 규칙, DNS 처리를 담당합니다. 설치가 완료되어도 사용할 수 있는 노드가 자동으로 생기는 것은 아닙니다. 이어서 사용 권한이 있고 출처가 신뢰할 수 있으며 현재 코어와 호환되는 설정이 필요합니다.
최초 설정 전에 프록시가 활성화되지 않은 상태에서 평소 직접 접속할 수 있는 웹사이트를 열어 로컬 Wi-Fi, 모바일 데이터 또는 유선 네트워크가 정상인지 확인합니다. 기기에서 네트워크 인증 페이지 로그인이 필요하면 먼저 인증을 완료하세요. 기존 시스템 프록시 설정을 기록하고, 이미 설정이 있다면 클라이언트의 내보내기 또는 백업 메뉴로 별도 저장합니다. 다른 프록시 도구는 먼저 정상적으로 연결을 끊어 여러 프로그램이 시스템 프록시를 동시에 변경하거나 VPN 연결을 선점하지 않도록 합니다.
구독을 준비할 때 제공자가 전체 Clash 호환 YAML을 주는지, 순수 노드 목록을 주는지, 단일 노드 공유 URL을 주는지 확인하세요. 형식에 따라 가져오기 메뉴가 다를 수 있습니다. 구독 URL에는 계정 식별 정보가 포함될 수 있으므로 공개 스크린샷, 문의 내용 또는 온라인 변환 도구에 올리지 마세요. 이 글에서는 최초 연결에 필요한 절차만 다루며 DNS, 규칙 문법, 설정 병합의 자세한 내용은 설정 레퍼런스에서 확인할 수 있습니다.
첫 번째 단계: 구독 가져오기 및 현재 설정으로 지정
클라이언트에서 “설정”, “구독” 또는 “Profiles” 페이지를 열고 “새로 만들기”, “추가” 또는 “가져오기” 메뉴를 찾습니다. 원격 구독을 사용하는 경우 URL로 추가하는 방식을 선택하고 전체 URL을 주소 입력란에 붙여 넣습니다. 이름을 지정할 수 있다면 “일상 설정”처럼 알아보기 쉬운 이름을 사용하세요. 저장하기 전에 앞뒤에 공백, 줄바꿈 또는 메신저가 붙인 구두점이 없는지 확인한 뒤 저장 또는 가져오기를 누르고 다운로드와 파싱이 끝날 때까지 기다립니다.
가져오기가 완료되면 설정 목록에 새 항목이 나타나며 업데이트 시간이나 업데이트 메뉴가 함께 표시될 수 있습니다. 항목이 나타났다고 해서 반드시 활성화된 것은 아닙니다. 해당 항목을 누르거나 옆의 “사용”, “활성화”, “현재 설정으로 지정” 같은 메뉴를 선택해 화면에 이 설정이 현재 선택된 것으로 명확히 표시될 때까지 진행합니다. 그런 다음 프록시 페이지에서 설정에 포함된 정책 그룹과 옵션이 보이는지 확인하세요. 다운로드 완료 알림만으로 코어가 모든 필드를 정상적으로 수락했다고 판단할 수는 없습니다.
로컬 YAML은 파일 가져오기 메뉴 사용
로컬 설정 파일이 있다면 같은 페이지에서 “파일에서 가져오기”를 선택하고 시스템 파일 선택기로 실제 YAML 파일을 엽니다. YAML 본문을 구독 URL 입력란에 붙여 넣지 말고, 확장자만 바꾼 일반 텍스트를 호환 설정으로 사용하지도 마세요. 클라이언트가 파일을 복사하지 않고 직접 참조하는 방식이라면 안정적인 폴더에 파일을 보관해 가져온 뒤 원본을 옮기거나 삭제하지 않도록 합니다.
전체 설정에는 보통 노드 또는 노드 프로바이더, 정책 그룹, 규칙 등의 구조가 포함되지만 모든 구독이 노드를 주 설정 파일에 직접 기록하는 것은 아닙니다. 원격 프로바이더를 사용하는 경우 연결된 리소스 업데이트를 기다려야 할 수도 있습니다. 설정이 정상적으로 로드된 뒤 정책 그룹이 비어 있다면 곧바로 알 수 없는 필드를 수동으로 추가하지 말고, 해당 설정이 다른 리소스에 의존하는지와 그 리소스 로드에 실패했는지를 먼저 확인하세요.
가져오기에 실패했다면 다운로드와 파싱을 먼저 구분
시간 초과나 연결 실패가 표시되면 현재 네트워크에서 URL을 가져올 수 있는지, 구독이 아직 유효한지 먼저 확인합니다. YAML 파싱 오류나 알 수 없는 필드가 표시되면 오류에 나온 필드명과 줄 번호를 기록하세요. 서버가 반환한 로그인 페이지, 오류 페이지 또는 순수 노드 목록을 클라이언트가 설정으로 읽다가 오류가 발생할 수도 있습니다. 브라우저에서 주소가 열린다고 해서 반환된 내용이 사용할 수 있는 설정이라는 뜻은 아니며, 인증 정보가 포함된 URL을 공개 웹사이트에 입력해서도 안 됩니다.
이때는 먼저 원본 파일을 보존하고 클라이언트 데이터를 서둘러 삭제하지 마세요. 제공자에게 구독 형식과 호환 코어를 확인하거나 구독 URL, 전체 YAML, 공유 URL의 차이를 참고해 올바른 메뉴를 선택합니다. 최초 가져오기 직후에는 자동 업데이트 주기를 지나치게 짧게 설정하지 말고, 설정이 정상적으로 작동하는지 확인한 뒤 업데이트 주기를 정하세요. 로컬 수정은 별도의 오버라이드에서 처리해 다음 업데이트로 변경 사항이 덮어쓰이지 않게 합니다.
두 번째 단계: 규칙 모드 및 프록시 출구 선택
방금 가져온 설정이 선택된 상태에서 홈, 프록시 또는 설정 페이지의 “모드” 메뉴를 찾습니다. 처음에는 “규칙” 또는 “Rule”을 선택하는 것이 좋습니다. 이 모드에서는 설정의 규칙에 따라 특정 연결을 직접 연결할지, 프록시 정책 그룹으로 보낼지, 거부할지를 코어가 결정하므로 분기 규칙이 포함된 전체 설정에 적합합니다. 가져온 내용에 노드만 있고 규칙과 정책 그룹이 없다면 모드 전환으로 분기 설정이 자동 생성될 것이라 기대하지 말고 호환되는 설정을 먼저 보완하세요.
자주 사용되는 다른 모드는 “전역”과 “직접 연결”입니다. 전역 모드는 보통 코어에 들어온 트래픽을 전역 정책으로 처리하지만 클라이언트를 우회하는 앱까지 자동으로 연결하지는 않습니다. 직접 연결 모드는 연결된 트래픽을 대상에 바로 접속시키는 데 사용됩니다. 두 모드는 문제 범위를 좁히는 데 도움이 되지만 올바른 규칙 설정을 대신할 수는 없습니다. 모드 선택과 트래픽 연결은 서로 다른 단계이므로 전역을 선택했다고 시스템의 모든 프로그램이 프록시를 사용하는 것은 아닙니다.
정책 그룹에서 실제 출구 확인
규칙 모드를 선택한 뒤 “프록시” 또는 “정책 그룹” 페이지를 엽니다. 설정에 표시된 그룹 이름을 기준으로 일반 프록시 트래픽을 담당하는 그룹을 찾습니다. “프록시 선택”, “Proxy” 또는 제공자가 지정한 이름일 수 있습니다. 그룹을 펼쳐 사용 권한이 있고 정상 작동하는 노드를 선택하세요. 그룹 안에 다른 정책 그룹이 있으면 현재 선택 항목을 계속 확인해 최종적으로 사용할 노드, 자동 선택 그룹 또는 직접 연결 정책을 명확히 파악합니다.
목록의 첫 번째 항목이라는 이유만으로 바로 선택하지 마세요. 특히 DIRECT는 직접 연결을 의미하므로 선택하면 일반적으로 원격 프록시 노드를 거치지 않습니다. 해당 그룹과 일치하는 연결을 프록시로 보내려면 최종 출구가 직접 연결이 아닌지 확인하세요. 자동 선택 그룹은 설정된 탐색 로직에 따라 후보를 선택할 수 있지만 후보 노드가 유효하고 탐색 주소에 도달할 수 있으며 클라이언트가 관련 설정을 정상적으로 로드했다는 전제가 필요합니다.
화면에 연결 테스트가 있다면 후보 노드를 한 번 테스트해 명백히 접근할 수 없는 항목을 걸러낼 수 있습니다. 테스트 성공은 특정 시점에 특정 탐색 요청이 완료됐다는 뜻일 뿐 모든 웹사이트, 프로토콜 또는 앱이 정상 작동한다는 의미는 아닙니다. 테스트 실패도 탐색 주소의 문제일 수 있습니다. 최초 설정에서는 확인된 출구 하나를 고정해 자동 노드 전환과 규칙 점검을 동시에 진행하지 않는 것이 결과를 비교하기 쉽습니다.
먼저 화면에서 설정하고 필드 편집은 나중에
이 단계에서 “최적화”를 위해 DNS, TUN, 규칙 목록을 동시에 수정할 필요는 없습니다. 일부 클라이언트는 화면 설정이나 로컬 오버라이드로 구독의 같은 이름 필드를 덮어쓰므로 파일에 mode: rule이 있어도 화면에는 다른 모드가 표시될 수 있습니다. 우선 클라이언트에서 최종 적용된 모드를 확인하고, 필드와 화면이 계속 다를 때 오버라이드 및 병합 안내를 참고하세요. 규칙 모드와 정책 그룹 출구를 확인한 뒤에 시스템 연결을 시작합니다.
세 번째 단계: 연결 및 트래픽 연결 활성화
먼저 클라이언트 홈으로 돌아가 코어가 정상적으로 시작되는지 확인합니다. 화면은 열리지만 상태에 시작 실패가 계속 표시된다면 로그에서 포트 충돌, 설정 로드 또는 권한 오류를 먼저 확인하세요. 이 상태에서 시스템 프록시를 켜면 앱이 작동하지 않는 로컬 주소로 연결될 수 있습니다. 코어가 정상 실행되고 설정이 로드된 뒤에만 앱 트래픽을 코어로 전달하는 것이 좋습니다.
데스크톱: 먼저 시스템 프록시로 브라우저 확인
Windows, macOS 또는 해당 연동을 지원하는 Linux 데스크톱 클라이언트에서 “시스템 프록시” 스위치를 찾아 켭니다. 이 작업은 보통 시스템 프록시를 로컬 수신 주소와 포트로 지정합니다. 그런 다음 운영체제의 프록시 설정에서 실제 값을 확인하고 주소와 포트가 클라이언트 설정과 일치하는지 대조하세요. 클라이언트가 시스템 설정을 자동으로 변경하지 못한다면 다른 튜토리얼의 고정 포트를 그대로 사용하지 말고 클라이언트에 표시된 실제 수신 값을 기준으로 직접 설정합니다.
예를 들어 클라이언트가 실제로 혼합 포트 7890을 사용할 때만 로컬 앱의 HTTP 프록시를 127.0.0.1:7890으로 설정할 수 있습니다. 이 숫자는 설명을 위한 예시일 뿐 기기의 현재 상태를 확인한 결과가 아닙니다. 클라이언트가 포트를 변경하면 시스템이나 앱의 설정도 함께 바꿔야 합니다. 처음에는 로컬 기기에서만 사용할 것이므로 LAN 액세스를 켤 필요가 없으며, 문제를 확인한다는 이유로 다른 기기에 수신 포트를 노출해서도 안 됩니다.
시스템 프록시는 해당 설정을 따르는 앱을 먼저 확인할 때 적합합니다. 일부 브라우저 확장 프로그램은 자체 프록시 설정을 사용하고 일부 명령줄 도구, 게임, 앱은 시스템 프록시를 읽지 않습니다. 따라서 브라우저는 접속되지만 특정 프로그램만 실패한다면 노드 전체가 작동하지 않는다고 판단하기 전에 해당 프로그램의 연결 방식을 확인하세요. Linux에서는 데스크톱 환경과 앱마다 프록시 설정을 읽는 방식이 다를 수 있습니다.
모바일: 연결 버튼으로 시스템 권한 승인
Android 또는 iOS 클라이언트에서 설정과 정책 그룹을 확인한 뒤 홈 화면의 연결 버튼을 누릅니다. 처음 사용할 때는 운영체제가 제공하는 VPN 권한 안내가 표시되는 경우가 많습니다. 요청을 시작한 앱이 방금 설치해 사용하려는 클라이언트인지 확인한 뒤 안내에 따라 허용하세요. 클라이언트로 돌아가 연결 상태가 전환될 때까지 기다립니다. 시스템에 VPN 아이콘이 표시되면 터널 인터페이스가 활성화된 상태라는 뜻이지만 원격 노드에 도달할 수 있거나 모든 규칙이 예상대로 적용된다는 의미는 아닙니다.
연결할 수 없다면 먼저 다른 VPN이 연결 슬롯을 사용 중인지, 클라이언트에 앱별 제외 설정이 있는지 확인합니다. Android 기기에서 잠금 화면이나 백그라운드 전환 후에만 연결이 끊긴다면 백그라운드 실행과 배터리 제한을 추가로 확인하세요. 처음부터 모든 시스템 권한을 한꺼번에 허용할 필요는 없습니다. iOS에서는 시스템 권한 절차가 실제로 완료됐는지 먼저 확인한 뒤 클라이언트로 돌아가 오류를 확인하고 같은 구독을 반복해서 가져오지 않도록 합니다.
이 단계가 끝나면 클라이언트를 계속 실행하고 당분간 설정, 노드 또는 연결 방식을 바꾸지 마세요. 다음으로 새로운 실제 요청을 보내 결과를 확인하면 모든 관찰이 동일한 설정을 기준으로 이루어집니다.
네 번째 단계: 요청, 규칙 및 접속 결과 확인
브라우저를 열고 새 페이지에서 프록시 규칙과 일치할 것으로 예상되는, 접속 권한이 있는 HTTPS 웹사이트를 방문합니다. 이미 열려 있는 기존 탭만 확인하지 마세요. 캐시, 연결 재사용 또는 기존 세션 때문에 새 연결이 발생하지 않았는데도 화면이 정상처럼 보일 수 있습니다. 그런 다음 클라이언트의 “연결” 또는 “로그” 페이지로 돌아가 방금 요청한 대상 도메인과 시간을 찾습니다. 클라이언트마다 표시 필드가 다를 수 있으므로 실제로 확인 가능한 정보를 기준으로 판단하세요.
확인은 세 단계로 나눠 진행합니다. 요청이 코어에 들어갔는지, 어떤 규칙이나 정책 그룹이 적용됐는지, 연결이 실제로 완료됐는지를 확인합니다. 대상 기록이 보이면 먼저 출구가 두 번째 단계에서 선택한 항목과 같은지 확인하세요. 직접 연결 규칙이 적용됐다면 웹사이트가 열려도 프록시 노드가 정상 작동한다고 볼 수 없습니다. 관련 기록이 전혀 보이지 않으면 먼저 로그 필터와 기록 범위를 확인한 다음 앱이 시스템 프록시를 우회했거나 VPN 연결 대상에서 제외됐는지 점검합니다.
프록시 요청과 직접 연결 요청을 나누어 확인
이어서 직접 연결될 것으로 예상되는 사이트에 접속해 규칙에서 어떻게 처리됐는지 확인합니다. 두 종류의 요청이 모두 예상대로 처리되는지 확인하는 편이 단일 출구 IP를 보는 것보다 규칙 분기가 올바른지 판단하는 데 유용합니다. 출구 IP 조회는 보조 확인 수단일 뿐입니다. 규칙 모드에서는 조회 사이트마다 다른 정책을 사용할 수 있으므로 한 번의 조회로 모든 앱의 출구를 판단할 수 없습니다. 클라이언트 로그가 간단한 경우에는 대상과 노드를 고정하고 설정을 하나씩 바꾸기 전후의 결과를 비교하세요.
웹페이지는 열리지만 특정 앱을 사용할 수 없다면 세 번째 단계로 돌아가 해당 앱의 프록시 설정, 브라우저 확장 프로그램 또는 앱별 제외 항목을 확인합니다. 로그에 파싱 오류가 나타나면 대상 도메인 해석 실패인지 노드 서버 주소 해석 실패인지 먼저 구분하세요. 두 문제의 위치가 다르므로 모두 노드 시간 초과로 처리해서는 안 됩니다. DNS 연결 및 누출 확인은 시스템 암호화 DNS, 브라우저 보안 DNS, TUN 라우팅의 영향도 받습니다. 자세한 점검은 DNS 설정 섹션을 참고하고, 이번에는 재현 가능한 기록을 보존하세요.
실패할 때는 한 번에 변수 하나만 변경
연결을 활성화한 뒤 모든 웹페이지가 열리지 않는다면 먼저 시스템 프록시를 끄거나 클라이언트 VPN 연결을 끊고 원래 직접 접속되던 사이트를 테스트합니다. 끈 뒤 정상으로 돌아오면 다음 점검에서는 로컬 수신 주소, 현재 설정, 원격 경로를 중점적으로 확인해야 합니다. 꺼도 계속 실패한다면 로컬 네트워크, 네트워크 인증 또는 기존 시스템 설정부터 처리하세요. 네트워크를 복구한 뒤 구독 유효성, 노드 매개변수, 연결 로그를 순서대로 확인하고 클라이언트 재설치를 첫 단계로 삼지 마세요.
특정 노드만 실패한다면 같은 대상과 같은 모드를 유지한 채 정상 작동이 확인된 다른 노드와 비교합니다. 특정 웹사이트만 실패한다면 노드는 그대로 두고 해당 사이트에 적용된 규칙과 오류 유형을 확인하세요. “대상, 시간, 사용한 정책, 오류 요약”만 기록하고 전체 구독 URL이나 인증 정보는 공개하지 마세요. 추가적인 단계별 점검은 노드 시간 초과 점검 순서를 참고하고, 코어 로드 실패가 발생하면 설정 검증 및 문제 해결을 확인하세요.
사용 가능한 기준 상태와 종료 방법 보존
프록시와 직접 연결 요청이 모두 예상대로 처리되면 현재 사용 가능한 설정과 로컬 설정을 백업한 뒤 자동 업데이트, 시작 시 실행 또는 복잡한 규칙 변경을 검토합니다. 한 번에 기능 하나만 추가하고 문제가 생기면 이 기준 상태로 되돌리세요. 사용을 중단할 때는 먼저 클라이언트에서 시스템 프록시를 끄고 VPN 연결을 끊거나 TUN을 비활성화한 다음 프로그램을 종료합니다. 비정상 종료 후 인터넷이 되지 않으면 시스템이 종료된 로컬 포트를 계속 가리키는지 확인하고 작업 전 기록한 프록시 설정을 복원하세요.