시작 전: 클라이언트와 호환 구독 준비
먼저 현재 운영체제와 CPU 아키텍처에 맞는 클라이언트를 설치하고, 프록시를 끈 상태에서도 기기가 기본 네트워크에 정상적으로 연결되는지 확인하세요. 아직 다운로드 전이라면 Clash 클라이언트 설치 파일 페이지에서 플랫폼을 선택하세요. 운영체제별 설치 권한, 서비스 모드, 패키지 형식은 전체 플랫폼 설치 및 설정 가이드에서 확인할 수 있습니다. 이 페이지는 클라이언트를 실행할 수 있는 상태부터 설명합니다.
이어서 서비스 제공자가 발급한 구독 URL을 준비하고 Clash 또는 mihomo 호환 형식인지 확인하세요. 구매 내역 페이지, 계정 로그인 URL, 구독 URL은 서로 다릅니다. 구독은 일반적으로 프록시, 프록시 그룹, 규칙이 포함된 설정을 반환하며, 브라우저에서 로그인하는 웹페이지가 아닙니다. 개별 노드 공유 링크만 있다면 클라이언트가 직접 가져오기를 지원하는지 먼저 확인하세요. 아무 링크나 구독 입력란에 붙여 넣는다고 자동으로 인식되는 것은 아닙니다.
구독 URL에는 계정 접근 정보가 포함될 수 있으므로 비밀번호처럼 취급하세요. 공개 댓글에 올리거나, 전체 주소가 보이는 화면을 모르는 사람에게 보내거나, 온라인 변환 사이트에 함부로 업로드하지 마세요. 구독 변환이 꼭 필요하다면 자주 묻는 질문의 구독 안내에서 설정 호환성과 주소 노출 위험을 먼저 확인하세요. 작업 전에는 다른 프록시나 VPN 클라이언트를 잠시 종료해 시스템 프록시, 가상 네트워크 어댑터, DNS 처리 간 충돌을 줄이는 것이 좋습니다.
1단계: 구독을 가져와 설정 활성화하기
클라이언트 사이드바에서 ‘구독’ 또는 ‘설정’ 페이지를 열고 ‘추가’, ‘가져오기’ 또는 더하기 버튼을 찾으세요. ‘URL에서 가져오기’와 ‘파일에서 가져오기’가 모두 있다면 구독 URL은 URL 가져오기를 선택합니다. 서비스 제공자가 내보낸 YAML 파일을 받은 경우에만 파일 가져오기를 사용하세요. 알아보기 쉬운 로컬 이름을 지정한 다음 전체 주소를 구독 입력란에 붙여 넣고, 앞뒤에 공백이나 줄바꿈이 섞이지 않았는지 확인한 뒤 확인을 누릅니다.
가져오기가 끝날 때까지 기다리고, 아직 모든 기능을 켜지는 마세요. 정상적으로 완료되면 설정 목록에 항목이 추가되고 최근 업데이트 결과가 표시됩니다. 일부 클라이언트는 프록시 개수나 업데이트 완료 메시지도 보여 줍니다. 해당 설정을 열거나 프록시 페이지로 이동하면 설정에 정의된 프록시 그룹과 후보 항목이 보여야 합니다. 화면이 계속 비어 있다면 주소만 저장되고 실제로 가져오기는 되지 않은 것은 아닌지 설정 페이지에서 확인하세요.
가져오기에 실패하면 해당 업데이트의 오류 메시지를 확인하세요. 시간 초과는 구독 서비스에 일시적으로 접근할 수 없거나 네트워크 경로에 문제가 있다는 뜻일 수 있습니다. 401, 403 등의 응답이 오면 서비스 제공자에게 주소와 접근 권한을 확인하세요. 파싱 오류는 형식이 호환되지 않거나 서버가 로그인 페이지를 반환했을 가능성이 있습니다. 이 오류를 모두 ‘노드 문제’로 취급하지 마세요. 아직 노드 연결 단계에 이르지 않았을 수도 있습니다. 오류의 핵심 문구를 기록하고, 로그를 공유할 때는 주소와 인증 정보를 가리세요.
설정이 목록에 나타난 뒤에는 ‘사용’, ‘활성화’를 누르거나 현재 설정으로 선택해야 합니다. 일부 클라이언트는 테두리나 선택 표시로 현재 항목을 구분합니다. 구독이 여러 개라면 방금 가져온 설정이 선택되어 있는지 확인한 다음 프록시 페이지에서 그룹을 살펴보세요. 다운로드에 성공했더라도 코어가 해당 설정을 불러온 것은 아닙니다. 설정을 한참 바꿨는데도 다른 설정에만 영향을 주는 경우는 처음 사용할 때 흔히 겪는 문제입니다.
구독은 나중에 ‘업데이트’를 눌러 다시 가져올 수 있습니다. 우선 기본 업데이트 방식을 그대로 사용하세요. 그룹 하나를 바꾸려고 원격 설정 내용을 직접 덮어쓰지는 마세요. 다음 업데이트 때 수동 변경 사항이 사라질 수 있습니다. 규칙을 계속 추가하거나 필드를 수정해야 한다면 전체 플랫폼 가이드에서 오버라이드와 로컬 설정 관리 방법을 확인하세요. 그룹이 나타나고 로드 오류가 없는 것을 확인한 뒤 실행 모드를 선택합니다.
2단계: 규칙 모드와 프록시 그룹 선택
‘프록시’ 페이지에서 ‘규칙 / 전역 / 직접 연결’ 모드 전환을 찾아 처음에는 ‘규칙’을 선택하세요. 규칙 모드는 현재 설정의 규칙 순서에 따라 요청을 처리할 정책을 결정하므로, 모든 사이트가 같은 프록시 연결을 사용하는 것은 아닙니다. 전역 모드는 코어로 들어오는 요청을 전역 정책으로 처리하고, 직접 연결 모드는 해당 요청을 프록시 노드로 전달하지 않습니다. 이 모드들은 코어가 트래픽을 처리하는 방식을 정할 뿐, 앱의 트래픽을 코어로 자동 전달하지는 않습니다.
이어서 주요 프록시 선택 그룹을 펼치세요. 그룹 이름은 구독 설정에 따라 ‘노드 선택’, ‘프록시’ 등으로 다를 수 있으니 모든 클라이언트에 공통으로 있는 이름을 찾을 필요는 없습니다. 그룹 안에서 사용할 노드를 눌러 선택하세요. 선택한 항목이 다른 그룹이라면 계속 펼쳐 실제 노드까지 선택했는지, DIRECT를 잘못 선택하지 않았는지 확인합니다. 자동 선택 그룹은 설정에 정의된 감지 및 선택 방식에 따라 작동하므로 특정 구성원을 직접 고정할 수 없는 경우도 있습니다.
클라이언트에 연결 테스트 버튼이 있다면 먼저 실행해 사용할 수 없는 후보를 걸러낼 수 있습니다. 테스트 주소에서 응답을 받았다고 해서 해당 경로에서 테스트가 성공했다는 뜻일 뿐, 대상 사이트도 반드시 열린다는 의미는 아닙니다. 숫자가 낮다는 이유만으로 전반적인 사용 경험을 판단해서도 안 됩니다. 테스트에서 사용할 수 있다고 확인된 노드를 하나 선택한 뒤 실제 사이트 요청으로 검증하세요. 모든 테스트가 실패하면 1단계로 돌아가 구독이 만료되었는지, 후보 항목이 제대로 들어왔는지 확인한 다음 네트워크 환경을 점검합니다.
‘어떤 사이트는 열리고 어떤 사이트는 열리지 않는’ 경우에는 잠시 전역 모드로 전환하고 전역 정책에서 노드를 선택해 비교할 수 있습니다. 같은 사이트가 전역 모드에서는 정상인데 규칙 모드에서만 문제가 생기면 규칙 적용 결과와 그룹 선택을 먼저 확인하세요. 두 모드 모두 실패한다면 노드나 연결 처리 상태를 계속 점검합니다. 비교가 끝나면 규칙 모드로 되돌려 문제 해결이 장기 설정으로 굳어지지 않게 하세요.
mode: rule위 내용은 모드 필드만 보여 주며, 화면의 ‘규칙’에 대응하는 예시일 뿐 단독으로 실행할 수 있는 완전한 설정이 아닙니다. 이 가이드에서는 YAML을 직접 수정할 필요가 없습니다. 먼저 화면에서 선택을 마치세요. 정책 그룹, 규칙, 노드의 관계가 여전히 헷갈린다면 용어 설명을 확인한 뒤 이 단계로 돌아오세요. 이제 활성화된 설정 하나, 명확한 모드 하나, 사용할 수 있는 프록시 선택 항목 하나가 준비되어야 합니다.
3단계: 연결을 켜고 시스템 권한 허용하기
데스크톱에서는 먼저 클라이언트 코어가 실행 중인지 확인한 뒤 ‘시스템 프록시’를 켭니다. 일반적으로 운영체제의 HTTP·HTTPS 프록시가 로컬 수신 주소를 가리키도록 설정되며, 시스템 프록시를 읽는 브라우저와 앱만 요청을 클라이언트로 보냅니다. 처음 설정할 때 브라우저 확장 프로그램, 환경 변수, 여러 네트워크 도구를 동시에 바꾸지 마세요. 경로를 단순하게 유지하면 문제가 생겼을 때 원인을 찾기 쉽습니다.
시스템 프록시가 켜져 있는데 브라우저에서 페이지가 전혀 열리지 않는다면 클라이언트 설정의 수신 포트와 시스템 네트워크 프록시의 주소 및 포트를 대조하세요. 흔히 사용하는 로컬 주소는 127.0.0.1이지만 포트는 현재 설정을 따라야 합니다. 가이드에 7890이 자주 나온다고 해서 기존 값을 그대로 덮어쓰지 마세요. 클라이언트가 정상적으로 수신하지 못하거나, 다른 프로그램이 포트를 사용 중이거나, 시스템이 이전 클라이언트를 가리키고 있으면 요청이 응답하지 않는 곳으로 전송될 수 있습니다.
Android와 iOS에서는 보통 메인 화면에서 ‘연결’ 또는 시작 버튼을 누르면 시스템이 VPN 구성이나 연결 권한을 요청합니다. 현재 사용하는 클라이언트가 권한을 요청하는지 확인하고 시스템 안내에 따라 허용하세요. 권한을 허용한 뒤 클라이언트에 연결됨으로 표시되는지 확인합니다. 시스템에도 VPN 상태 표시가 나타날 수 있습니다. 여기서 VPN은 시스템이 제공하는 트래픽 처리 인터페이스를 뜻하며, VPN이라고 표시된 모든 앱이 같은 프로토콜이나 서버를 사용하는 것은 아닙니다.
기기에서 다른 VPN, 회사 네트워크 터널 또는 유사한 프록시 도구를 이미 실행 중이라면 동시에 사용할 수 있는지 먼저 확인하세요. 모바일 운영체제는 보통 여러 VPN 서비스를 동시에 실행하지 못하게 하므로 나중에 시작한 서비스가 기존 연결을 대체할 수 있습니다. 회사나 학교에서 관리하는 네트워크라면 관리 정책을 임의로 변경하지 마세요. 네트워크 사용 요건을 확인한 뒤 테스트를 계속하세요. 연결 버튼을 눌러도 바로 꺼진다면 권한이 허용되었는지, 백그라운드 실행이 제한되어 있는지, 클라이언트에 설정 로드 오류가 표시되는지 확인합니다.
TUN은 시스템 프록시를 따르지 않는 앱의 트래픽까지 더 폭넓게 처리하는 기능이지만, 브라우저 연결을 처음 확인할 때 반드시 켤 필요는 없습니다. TUN을 사용하려면 데스크톱 클라이언트가 서비스 설치, 관리자 권한 또는 가상 네트워크 장치 허용을 요청할 수 있습니다. 현재 클라이언트의 문서에 따라 권한을 설정하세요. 시스템 프록시와 TUN을 반드시 동시에 켜야 하는 기능으로 생각하지 마세요. 활성화 후 기본 네트워크에도 문제가 생기면 TUN을 끄고 시스템 프록시 경로로 돌아가 설정이 작동하는지 확인한 다음 전체 플랫폼 가이드에서 라우팅, DNS, 권한 관련 세부 사항을 살펴보세요.
4단계: 요청, 규칙 및 실제 출구 확인
연결 상태는 시작일 뿐이며, 실제 요청이 처리되는지 확인해야 합니다. 먼저 기본 네트워크에서 접속할 수 있는 사이트를 브라우저로 열어 기존 연결에 문제가 없는지 확인한 다음 프록시로 접속하려는 사이트를 새 탭에서 엽니다. 이전 페이지나 기존 연결의 영향을 피하려면 새 시크릿 창을 사용하거나 페이지를 완전히 새로고침하세요. 대상 사이트가 열린 뒤에는 클라이언트의 ‘연결’ 또는 ‘로그’ 페이지를 확인하세요. 스위치 색상만으로 성공 여부를 판단하지 마세요.
연결 목록에서 대상 도메인을 찾아 방금 발생한 요청을 확인하고 적용된 규칙, 사용한 정책 그룹, 최종 노드를 살펴보세요. 프록시를 사용해야 하는 요청이 DIRECT로 표시되면 2단계로 돌아가 모드와 그룹을 확인합니다. 요청이 전혀 보이지 않으면 브라우저가 시스템 프록시를 읽는지, 프록시 확장 프로그램이 설정을 덮어쓰는지, 현재 창이 이전 연결을 계속 사용 중인지 점검하세요. 연결 목록에 활성 요청만 표시되는 경우도 있으므로 페이지 로드 후 항목이 사라져도 반드시 오류는 아닙니다. 새로고침하면서 목록을 함께 확인해 보세요.
신뢰할 수 있는 출구 IP 조회 서비스를 이용해 프록시를 끈 상태와 켠 상태의 결과를 비교하세요. 규칙 모드에서는 조회 사이트 자체가 직접 연결 규칙에 해당할 수도 있으므로 주소가 바뀌지 않았다고 해서 곧바로 프록시 실패로 볼 수는 없습니다. 해당 요청의 규칙 적용 기록도 함께 확인해야 합니다. 확실하게 비교하려면 노드를 선택한 전역 모드로 잠시 전환해 다시 조회한 다음 규칙 모드로 되돌리세요. 출구가 바뀌었다는 사실은 해당 요청의 경로가 달라졌다는 뜻일 뿐, 기기의 모든 앱 트래픽이 처리되고 있다는 의미는 아닙니다.
‘코어가 프록시할 수 있는지’와 ‘브라우저 트래픽이 코어로 전달되는지’를 더 정확히 구분하려면 데스크톱에서 터미널을 이용해 로컬 HTTP 프록시로 요청을 직접 보낼 수 있습니다. 아래 명령은 현재 HTTP 또는 mixed 수신 포트가 실제로 7890인 경우에만 사용할 수 있습니다. 포트가 다르면 먼저 값을 바꾸세요. 예시 도메인은 HTTP 응답 테스트용이며 특정 지역에서 접속할 수 있는지 판단하는 용도가 아닙니다.
curl -I --proxy http://127.0.0.1:7890 https://example.comWindows 터미널에서 curl을 다른 명령으로 인식한다면 curl.exe를 사용하세요. HTTP 응답을 받으면 지정한 로컬 프록시를 통해 응답을 가져왔다는 뜻이지만, 직접 연결인지 노드를 거쳤는지는 로그에서 확인해야 합니다. 연결이 거부되면 포트와 코어 실행 상태를 확인하고, 오랫동안 시간 초과가 발생하면 노드와 대상 사이트까지의 경로를 살펴보세요. 이 테스트는 시스템 프록시 설정을 자동으로 바꾸지 않으며 브라우저 테스트를 대신할 수도 없습니다. 두 경로를 구분해서 이해하세요.
마지막으로 DNS가 어떻게 처리되는지도 확인하세요. 사이트가 열린다는 사실만으로 DNS 트래픽이 예상대로 처리된다고 단정할 수는 없습니다. DNS 검사 페이지에 표시된 리졸버 위치만으로 유출 여부를 확정해서도 안 됩니다. 처음에는 작동하는 설정을 유지하세요. 도메인을 확인할 수 없거나 일부 사이트만 문제가 생기거나 Clash DNS 유출을 확인해야 한다면 자주 묻는 질문에서 증상에 따라 점검하세요. DNS 필드와 네트워크 스택 개념은 용어 설명에서 확인할 수 있습니다. 요청이 코어에 전달되는지 확인하기 전에는 모든 DNS 값을 한꺼번에 바꾸지 마세요.
완료 후: 설정 기록 및 안전하게 종료하기
대상 사이트에 접속할 수 있고 연결 기록이 예상한 정책과 일치하며 기본 네트워크도 정상이라면 첫 설정이 완료된 것입니다. 설정 이름, 실행 모드, 프록시 그룹 선택만 기록해 두세요. 전체 구독 URL이 보이는 화면을 저장할 필요는 없습니다. 이후에는 일상적으로 사용하는 앱을 하나씩 테스트하세요. 브라우저는 되는데 특정 프로그램만 안 된다면 구독 전체를 바로 바꾸기보다 먼저 해당 프로그램의 프록시 지원 여부를 확인하는 것이 좋습니다.
사용을 마치려면 데스크톱에서 먼저 시스템 프록시를 끄거나 클라이언트의 정상 종료 기능으로 설정을 복구한 뒤 프로세스를 종료하세요. 모바일에서는 연결 해제를 누르고 시스템 VPN 상태도 종료되었는지 확인합니다. 클라이언트가 비정상적으로 종료된 뒤 브라우저에서 페이지가 열리지 않으면 시스템 프록시가 중지된 로컬 포트를 계속 가리키는지 확인하세요. 프로그램을 계속 재설치하기보다 네트워크 설정을 복구하는 편이 빠릅니다. 이 문제만으로 모든 설정 파일을 삭제할 필요는 없습니다.
문제가 생길 때마다 같은 순서로 확인하세요. 구독이 정상적으로 로드되었는지, 모드와 정책 그룹이 맞는지, 앱 요청이 코어에 전달되는지, 규칙과 출구가 예상대로 적용되는지 점검합니다. 한 번에 변수 하나만 바꾸고 테스트한 뒤 다음 단계로 넘어가세요. 플랫폼 설치, TUN, 장기적인 설정 오버라이드는 전체 플랫폼 가이드에서 확인하고, 구체적인 오류는 자주 묻는 질문에서 검색하세요. 먼저 반복해서 확인할 수 있는 연결 경로를 확보한 다음 설정을 확장하세요.