Clash 사용법 가이드

1단계: 구독 가져오기

먼저 사용할 수 있는 설정을 클라이언트로 가져온 다음 연결을 시작하세요. 클라이언트가 설정을 읽고 출구를 선택해 트래픽을 전달합니다. 프로그램을 설치하는 것만으로 프록시 서비스가 생성되지는 않습니다. 시작하기 전에 서비스 제공자가 안내한 Clash 호환 구독 링크나 사용할 수 있는 로컬 YAML 설정 파일을 준비하세요. 구독 주소에는 계정 권한이 연결되는 경우가 많으므로 신뢰할 수 있는 클라이언트에만 저장하고, 공개 게시판이나 스크린샷, 낯선 온라인 변환 사이트에는 붙여넣지 마세요.

구독 URL로 설정 추가

클라이언트를 열고 “설정”, “구독” 또는 “Profiles” 페이지로 이동한 뒤 “추가”, “가져오기” 또는 더하기 버튼을 찾으세요. URL 가져오기를 선택하고 구독 주소 전체를 붙여넣습니다. 이름 입력란이 있다면 “일상용 설정”처럼 알아보기 쉬운 이름을 지정할 수 있습니다. 이름은 기기에서 설정을 구분하는 용도일 뿐, 구독에 포함된 노드나 규칙에는 영향을 주지 않습니다. 저장하기 전에 주소 앞뒤에 공백이 없는지 확인하고, 서비스 제공자의 계정 관리 페이지 주소를 구독 주소로 착각하지 않도록 주의하세요.

다운로드 또는 저장을 누른 뒤 설정 목록에 새 항목이 나타날 때까지 기다리세요. 업데이트 시간이 표시되고 설정 이름이 보이며 파싱 오류가 없다면 대체로 정상입니다. 해당 항목이나 “활성화” 버튼을 눌러 현재 설정으로 지정하세요. 일부 클라이언트는 가져온 파일을 저장만 하고 자동으로 전환하지 않습니다. “사용 중” 표시가 보이거나 프록시 페이지에 해당 정책 그룹이 나타나야 이 단계를 마친 것입니다. 이때 트래픽 전달 스위치를 여러 개 켜지 말고, 설정을 제대로 읽었는지 먼저 확인하세요.

로컬 파일 가져오기 및 오류 해결

.yaml 또는 .yml 파일을 받았다면 같은 페이지에서 “파일 가져오기”를 선택하고 파일 선택 창에서 해당 파일을 고른 다음 설정을 활성화하세요. 모바일에서는 시스템 공유 메뉴로 파일을 클라이언트에 전달할 수도 있습니다. 이용 가능한 방법은 클라이언트 지원 여부에 따라 다릅니다. 로컬 파일은 원격 구독처럼 자동 업데이트되지 않는 경우가 많으므로, 나중에 다시 가져오거나 클라이언트의 편집·덮어쓰기 기능으로 관리해야 합니다.

“형식 오류” 또는 “파싱 실패”가 표시되면 먼저 구독 출력 형식이 해당 클라이언트에서 지원하는 Clash 설정인지 확인하세요. 웹페이지 내용, 단일 프로토콜 링크, Base64 노드 목록은 올바른 설정 형식이 아닐 수 있습니다. 시간 초과가 발생하면 현재 네트워크에서 구독 서비스에 접속할 수 있는지 확인하세요. 다운로드 오류를 해결하려고 DNS, TUN, 포트를 한꺼번에 변경하지 마세요. 사용할 수 있는 출구와 해당 정책이 포함되어야 하며, 서비스 제공자마다 설정 구조가 다르므로 파일 확장자만으로 호환 여부를 판단할 수 없습니다.

완료되면 프록시 페이지로 돌아가 정책 그룹이나 선택 가능한 출구가 표시되는지 확인한 뒤 다음 단계로 진행하세요. 구독 업데이트에 실패해도 일부 클라이언트는 이전에 사용하던 설정을 유지합니다. 그렇다고 최신 내용이 내려받아졌다는 뜻은 아닙니다. 형식과 업데이트 설정은 구독 링크 가져오기 및 자주 쓰이는 형식 안내에서 확인하세요. 가져온 뒤에도 정책 그룹이 나타나지 않는다면 FAQ의 설치 및 설정 문제를 참고하세요.

2단계: 프록시 모드 선택

처음 사용할 때는 규칙 모드를 권장합니다. 규칙 모드는 현재 설정의 규칙에 따라 연결을 직접 처리하거나 프록시 정책 그룹으로 보냅니다. 일상적인 사용에 적합합니다. 클라이언트의 홈, 대시보드 또는 프록시 페이지에서 “모드” 항목을 찾아 “규칙” 또는 “Rule”을 선택하세요. 이 설정은 트래픽이 커널에 들어온 뒤 처리되는 방식을 바꿀 뿐, 브라우저나 다른 앱의 트래픽을 클라이언트로 전달하지는 않습니다. 트래픽 전달은 다음 단계에서 설정합니다.

일반적으로 사용하는 모드는 규칙, 전역, 직접 연결 세 가지입니다. 전역 모드에서는 커널에 들어온 요청을 전역 정책으로 처리하지만, 실제 프록시 사용 여부는 전역 정책에서 어떤 출구를 선택했는지에 따라 달라집니다. 컴퓨터의 모든 앱이 자동으로 연결되는 것은 아닙니다. 직접 연결 모드에서는 커널에 들어온 연결이 대상에 바로 접속합니다. 처음 설정할 때 세 모드를 번갈아 시험할 필요는 없습니다. 규칙 모드를 유지하면 이후 연결 기록을 규칙에 따라 확인하기 쉽습니다.

정책 그룹에서 출구 선택

“프록시” 또는 “Proxies” 페이지를 열고 일상적인 접속에 사용할 기본 정책 그룹을 찾으세요. “프록시 선택”, “노드 선택”이라는 이름일 수도 있고, 서비스 제공자가 지정한 이름을 사용할 수도 있습니다. 그룹을 펼쳐 사용할 수 있는 출구를 선택하세요. 설정에 자동 선택 그룹이 있다면 우선 그대로 사용해도 됩니다. 그룹 안의 항목은 개별 노드일 수도 있고 다른 정책 그룹일 수도 있으므로, 그룹 이름만 확인하고 끝내지 말고 현재 선택을 따라가 최종 출구를 확인하세요.

DIRECT는 직접 연결, REJECT는 연결 거부를 뜻하며 프록시 노드가 아닙니다. 프록시를 사용해야 하는 정책 그룹에서 둘 중 하나를 잘못 선택하면 출구가 바뀌지 않거나 페이지 접속에 실패할 수 있습니다. 모든 정책 그룹을 같은 노드로 바꾸지 마세요. 설정에 따라 서비스별 그룹이 따로 있을 수 있으므로 기존 구성을 유지하는 편이 사용과 문제 해결에 유리합니다. 이번에 확인할 대상에 실제로 적용되는 정책 그룹만 조정하세요.

클라이언트에 연결 테스트 기능이 있다면 기본 정책 그룹에서 테스트를 실행해 출구가 응답하는지 확인하세요. 테스트 결과는 지정된 테스트 주소까지 연결되는지만 보여줍니다. 모든 웹사이트의 접속 가능 여부나 실제 다운로드 속도를 의미하지는 않습니다. 테스트가 전부 실패하면 노드가 불러와졌는지, 서비스 계정이 유효한지, 기기 시간이 정확한지 확인한 다음 네트워크를 점검하세요. 속도 테스트를 반복한다고 연결 문제가 해결되지는 않습니다.

이제 모드가 규칙으로 설정되어 있고 기본 정책 그룹에 출구가 지정되어 있는지 확인하세요. 두 설정은 그대로 두고 트래픽 전달을 켜면 됩니다. 자동 선택, 장애 조치, 부하 분산의 차이를 알아보려면 나중에 정책 그룹 항목 참고를 확인하세요. 첫 연결을 위해 정책 그룹을 직접 작성하거나 규칙 순서를 바꿀 필요는 없습니다.

3단계: 연결 켜기

앱의 트래픽이 클라이언트로 들어와야 규칙 모드가 처리할 수 있습니다. 데스크톱의 시스템 프록시와 TUN, 모바일의 VPN 권한은 서로 다른 트래픽 전달 방법이며 규칙·전역·직접 연결 모드와 혼동하면 안 됩니다. 처음에는 현재 플랫폼에서 가장 간단한 방법 하나를 사용하고, 연결을 확인한 뒤 적용 범위를 넓히세요. 시작하기 전에 같은 트래픽을 처리할 수 있는 다른 프록시나 VPN 도구를 종료해 라우팅과 시스템 설정이 서로 덮어쓰지 않도록 하세요.

데스크톱: 먼저 시스템 프록시 사용

Windows, macOS 등 데스크톱 클라이언트의 홈이나 설정에서 “시스템 프록시” 스위치를 켜세요. 커널이 실행 중이고 현재 설정도 활성화되어 있어야 합니다. 일부 클라이언트에서는 먼저 시작 버튼을 누른 다음 시스템 프록시를 켜야 합니다. 시스템 프록시는 운영체제의 프록시 설정을 변경해 해당 설정을 따르는 앱이 기기의 로컬 수신 포트로 연결되도록 합니다. 처음 확인할 때는 시스템 프록시를 사용하는 브라우저를 이용하세요. 게임, 명령줄 도구, 자체 프록시를 설정한 앱으로 바로 테스트하지 않는 것이 좋습니다.

브라우저에 프록시 전환 확장 프로그램이 설치되어 있다면 시스템 설정을 덮어쓰고 있지 않은지 확인하세요. 프록시 주소를 직접 입력한 앱은 자체 설정을 계속 사용할 수도 있습니다. 브라우저마다 포트를 다시 입력할 필요는 없습니다. 우선 테스트용 브라우저가 시스템 프록시를 사용하도록 하세요. 일반적으로 클라이언트가 실행 중이면 브라우저에서 새로 요청한 트래픽이 커널로 들어갑니다. 창을 최소화해도 대개 실행에는 문제가 없지만, 클라이언트를 완전히 종료하면 연결이 끊길 수 있습니다. 백그라운드 서비스 동작은 클라이언트마다 다릅니다.

시스템 프록시를 따르지 않는 앱까지 연결해야 할 때만 TUN 사용을 고려하세요. TUN을 켜면 클라이언트에서 서비스 설치, 가상 네트워크 어댑터 생성 또는 관리자 권한을 요구할 수 있습니다. 신뢰할 수 있는 클라이언트의 안내에 따라 진행하세요. 시스템 프록시와 TUN을 동시에 켰을 때의 동작은 클라이언트마다 다르므로, 처음 문제를 확인할 때는 안내된 트래픽 전달 경로 하나를 명확히 사용하세요. 로컬 네트워크 접속에 문제가 생기면 먼저 확인이 끝난 시스템 프록시 방식으로 되돌리고, 라우팅과 DNS를 한꺼번에 변경하지 마세요.

모바일: 시스템 연결 권한 확인

Android 또는 iOS 클라이언트에서 설정을 활성화하고 정책을 선택한 뒤 홈으로 돌아와 “연결” 또는 시작 버튼을 누르세요. 처음 연결할 때 운영체제에서 VPN 설정 추가 또는 VPN 연결 허용을 요청할 수 있습니다. 현재 사용 중인 클라이언트가 보낸 요청인지 확인한 뒤 승인하세요. 요청을 거부하면 설정을 가져왔더라도 시스템 트래픽이 클라이언트로 전달되지 않습니다. 권한을 승인한 뒤 클라이언트로 돌아와 연결됨 또는 실행 중으로 표시되는지 확인하세요.

시스템에 VPN 아이콘이 표시되면 트래픽 전달 통로가 설정된 것입니다. 프록시 출구가 정상적으로 작동한다는 뜻은 아닙니다. 일부 클라이언트는 앱별로 트래픽을 전달하거나 제외할 수 있습니다. 이 설정을 변경했다면 테스트할 브라우저가 전달 대상에 포함되어 있는지 확인하세요. 백그라운드 절전 설정 때문에 시간이 지나면 클라이언트가 종료될 수도 있습니다. 처음 연결을 확인할 때는 앱을 실행 상태로 유지하고, 연결에 성공한 뒤 필요한 백그라운드 활동을 운영체제 설정에서 허용하세요.

이 단계가 끝나면 커널이 실행 중이고 시스템 프록시가 켜져 있거나, 모바일 연결 상태가 정상이어야 합니다. 수신 포트 오류가 표시되면 포트 충돌부터 해결하세요. 권한 창이 나타나지 않으면 클라이언트에 이미 시스템 권한이 있는지 또는 다른 VPN 연결이 실행 중인지 확인하세요. 추가 문제는 문제 해결 FAQ에서 확인할 수 있습니다. 시스템 프록시와 가상 네트워크 어댑터의 차이는 TUN 모드와 시스템 프록시 비교를 참고하세요.

4단계: 적용 여부 확인

스위치 상태만 보지 말고 실제 요청과 연결 기록으로 확인하세요. 클라이언트를 실행 상태로 둔 채 브라우저의 새 탭에서 평소 접속할 수 있는 페이지를 열어 기본 네트워크 연결이 유지되는지 확인합니다. 그런 다음 현재 규칙상 프록시를 거쳐야 하는 페이지에도 접속하세요. 이미 로드된 탭 대신 새 요청을 사용하는 것이 좋습니다. 캐시된 내용이나 기존 연결은 이전 경로를 계속 사용할 수 있기 때문입니다. 모드나 출구를 변경했다면 필요에 따라 기존 탭을 닫고 다시 접속하세요.

규칙, 정책 그룹 및 최종 출구 확인

클라이언트에서 “연결”, “Connections” 또는 요청 로그 페이지를 연 뒤 브라우저로 돌아가 대상 페이지를 새로고침하세요. 대상 도메인의 새 기록을 찾아 적용된 규칙, 사용한 정책 그룹, 최종 출구를 확인합니다. 클라이언트마다 표시되는 항목은 다르지만, 요청이 커널에 들어왔는지와 직접 연결됐는지 또는 선택한 프록시를 거쳤는지는 확인할 수 있어야 합니다. 홈 화면에 표시된 상태 문구를 추측하는 대신 방금 보낸 실제 요청을 확인하세요.

규칙 모드에서는 일부 요청이 직접 연결될 수 있으므로, 일반 웹페이지가 열리거나 특정 기록에 DIRECT가 표시된다는 사실만으로 프록시가 작동하지 않는다고 판단할 수 없습니다. 먼저 해당 대상이 설정상 프록시를 거쳐야 하는지 확인하고 실제 결과와 비교하세요. 공인 IP 출구를 확인하려면 신뢰할 수 있는 조회 서비스를 이용하면서 클라이언트에서 해당 조회 요청이 프록시 정책에 적용됐는지 확인하세요. 조회 페이지가 규칙상 직접 연결되도록 설정되어 있다면 현재 네트워크의 출구가 표시되는 것이 정상입니다.

연결이 정상이라면 대상 페이지가 열리고, 해당 요청이 클라이언트에 기록되며, 예상한 정책이 적용되고, 최종 출구가 선택한 노드와 일치해야 합니다. 브라우저 연결은 정상인데 특정 앱에서만 차이가 없다면 모든 노드를 바꾸기보다 트래픽 전달 범위를 확인하세요. 명령줄 프로그램, 별도 네트워크 스택을 사용하는 앱, 전용 프록시를 설정한 프로그램은 별도 설정이 필요하거나 적절한 TUN 전달 방식이 필요할 수 있습니다.

요청이 확인된 위치를 기준으로 문제 범위 좁히기

대상 페이지를 새로고침해도 연결 기록이 전혀 없다면 시스템 프록시가 켜져 있는지, 브라우저 설정이 시스템 설정을 덮어쓰는지, 모바일 연결이 유지되고 있는지 먼저 확인하세요. 연결 목록에 필터가 적용되어 있거나 요청 종료 후 활성 연결 목록에서 항목이 사라졌는지도 살펴보세요. 필요한 경우 로그를 확인하세요. 요청이 커널에 들어오지 않았다는 점을 확인한 뒤에만 트래픽 전달 경로를 점검하고, 노드 프로토콜 항목은 아직 변경하지 마세요.

기록은 있지만 대상 연결이 시간 초과된다면 최종 출구가 방금 선택한 노드인지 확인한 뒤 같은 그룹의 다른 출구를 사용해 보세요. 특정 도메인만 실패한다면 로그를 바탕으로 DNS 오류, 규칙 오적용, 대상 서비스 문제를 구분하세요. 모든 대상에서 실패한다면 서비스 이용 기간, 노드 상태, 현재 네트워크를 확인하세요. 한 번에 설정 하나만 변경하고 요청을 다시 보내 결과를 비교해야 어떤 변경이 효과가 있었는지 알 수 있습니다.

첫 연결 확인이 끝나면 규칙 모드와 정상 작동이 확인된 트래픽 전달 방식을 유지하고, 구독 업데이트 간격은 나중에 설정해도 됩니다. 데스크톱에서 클라이언트를 종료하기 전에 시스템 프록시를 끄거나 클라이언트가 시스템 설정을 정상적으로 복원하는지 확인하세요. 그러지 않으면 이미 종료된 로컬 포트로 앱이 계속 연결을 시도할 수 있습니다. 모바일에서는 클라이언트에서 연결을 끊고 시스템 연결 상태도 종료됐는지 확인하세요. 다음에 실행할 때는 대개 설정이 유효한지 확인하고 원하는 정책을 선택한 뒤 다시 연결하면 됩니다.

연결 확인이 끝나지 않았다면 클라이언트 이름, 운영체제, 사용한 트래픽 전달 방식, 오류가 발생한 단계를 기록한 뒤 자주 묻는 질문 및 문제 해결에서 해당 내용을 찾아보세요. 로그를 공유하기 전에는 구독 주소, 계정 정보, 노드 인증 정보를 가리세요. mixed-port, DNS 또는 사용자 지정 규칙을 조정해야 한다면 설정 파일 참고 문서를 확인하세요. 처음 연결을 위해 이미 정상적으로 불러온 설정 파일 전체를 교체하지 마세요.