Clash 첫 설치 후 초기 설정: 시스템 권한, 포트 충돌, 구독 가져오기 문제

초기 설정 순서: 먼저 코어를 실행하고 연결 확인하기

처음 실행한 뒤에는 클라이언트에서 코어가 정상적으로 실행되는지 확인하세요. 그다음 구독을 가져와 설정을 적용하고 노드를 선택한 후 시스템 프록시나 TUN을 켭니다. 포트, DNS, 라우팅 규칙을 한꺼번에 바꾸지 마세요. 한 번에 한 항목씩 점검해야 어떤 설정이 영향을 줬는지 알 수 있습니다.

Clash GUI 클라이언트는 화면과 시스템 연동을 담당하고, 코어는 설정을 파싱해 연결을 전달합니다. mihomo 코어를 사용할 때는 GUI가 정상적으로 열려도 설정이 로드되지 않았을 수 있습니다. 설정 목록에 표시된다고 해서 현재 실행 중인 설정이라는 뜻도 아닙니다. 네트워크를 테스트하기 전에 실행 상태와 시작 로그부터 확인하세요.

1. 설치 파일의 아키텍처를 확인하세요. 기기에 맞춰 x64 또는 ARM64를 선택하고, macOS도 프로세서 아키텍처를 확인해야 합니다. 아키텍처가 맞지 않으면 실행되지 않거나 시스템 변환 계층에 의존할 수 있습니다.
2. 초기 네트워크 상태를 유지하세요. 시스템 프록시, 가상 네트워크 어댑터, 기본 경로를 여러 프로그램이 동시에 변경하지 않도록 다른 프록시 클라이언트와 VPN을 먼저 종료하세요.
3. 코어가 실행 중인지 확인하세요. 클라이언트 로그에서 시작 결과를 확인하고, 설정 파싱 오류, 포트 바인딩 실패, 권한 오류부터 해결하세요.
4. 설정을 가져와 적용하세요. 구독을 업데이트한 뒤 사용할 설정을 직접 선택하고, 정책 그룹에 노드가 표시되는지 확인하세요.
5. 트래픽 처리 방식은 하나씩 테스트하세요. 데스크톱에서는 먼저 시스템 프록시를 사용하세요. 프록시 설정을 따르지 않는 앱까지 처리해야 할 때 TUN을 확인하면 됩니다.

Windows 첫 실행: 보안 경고, 서비스 권한, 방화벽 구분하기

먼저 출처를 확인한 뒤 설치 경고를 처리하세요

시스템 보안 경고가 표시되면 설치 파일의 출처와 다운로드 페이지 안내, 파일 속성을 먼저 확인하세요. 출처를 확인할 수 없다면 설치를 중단하세요. 회사나 기관에서 관리하는 기기라면 설치 정책과 관리자 권한은 기기 관리자에게 문의하세요. 클라이언트를 실행하려고 시스템 보호 기능 전체를 끄지 마세요.

Windows 11에서는 ‘설정’ → ‘시스템’ → ‘정보’에서 시스템 종류를 확인할 수 있습니다. 설치 후 GUI는 열리지만 코어가 바로 종료된다면 로그부터 확인하세요. GUI 프로그램을 다시 설치해도 YAML 형식 오류나 포트 점유 문제는 해결되지 않습니다.

서비스 모드와 시스템 프록시는 다릅니다

• 시스템 프록시: 시스템에 로컬 프록시 주소를 등록합니다. 일반적인 데스크톱 사용에서는 클라이언트를 항상 관리자 권한으로 실행할 필요가 없습니다.
• 서비스 모드: 백그라운드 서비스가 더 높은 권한이 필요한 작업을 수행합니다. 구체적인 범위는 클라이언트 구현에 따라 다릅니다. 서비스를 설치하거나 복구할 때 관리자 권한을 요청할 수 있습니다.
• TUN 모드: 가상 네트워크 인터페이스를 만들고 라우팅을 설정하므로 서비스 지원이나 관리자 권한이 필요한 경우가 많습니다. 서비스가 설치되어 있어도 TUN이 정상적으로 시작됐다는 뜻은 아닙니다.

TUN을 켠 뒤 로그에 권한 부족이 표시되면 먼저 클라이언트의 서비스 상태를 확인하세요. 가상 인터페이스나 라우팅 생성 실패가 표시된다면 다른 VPN이 네트워크를 제어하고 있는지도 확인하세요. 첫 번째 오류를 무시한 채 스위치만 반복해서 누르지 마세요.

사용 범위에 맞춰 방화벽을 허용하세요

이 기기에서만 사용할 때는 프록시가 루프백 주소에서 수신하도록 설정하면 됩니다. LAN에서 들어오는 연결까지 허용할 필요는 없습니다. 휴대폰에서 PC의 프록시를 사용하려면 ‘Windows 보안’ → ‘방화벽 및 네트워크 보호’에서 허용된 앱이나 인바운드 규칙을 확인하고 신뢰할 수 있는 네트워크로 범위를 제한하세요. 방화벽 허용과 클라이언트의 allow-lan 설정은 별개이며, 하나를 켜도 다른 하나를 대신할 수 없습니다.

macOS와 Android: 권한을 허용한 뒤에도 트래픽 처리 상태 확인하기

macOS: 설치를 마친 다음 보조 서비스 설정하기

설치 방법에서 앱을 ‘응용 프로그램’ 폴더로 드래그하라고 안내하면 먼저 해당 단계를 마친 뒤 실행하세요. 시스템에서 실행을 차단하면 출처를 확인한 후 ‘시스템 설정’ → ‘개인정보 보호 및 보안’의 관련 안내를 살펴보세요. 확인된 앱에만 권한을 허용하고 보안 설정을 전역적으로 낮추지 마세요. 안내 내용은 macOS 버전과 앱 서명 상태에 따라 달라질 수 있습니다.

클라이언트가 보조 도구나 서비스를 설치해 달라고 요청하면 방금 실행한 클라이언트에서 보낸 요청인지 확인한 다음 관리자 인증 정보를 입력하세요. 이 권한은 보통 시스템 네트워크 설정이나 TUN 지원에 사용됩니다. 구독 서비스 로그인 절차가 아니며, 구독 주소 입력 과정에서 기기의 관리자 암호를 요구해서도 안 됩니다.

시스템 프록시를 점검하려면 ‘시스템 설정’ → ‘네트워크’ → 현재 네트워크 연결 → ‘세부사항’ → ‘프록시’에서 기존 설정을 확인할 수 있습니다. HTTP와 HTTPS 프록시는 실제로 수신 중인 주소와 포트를 가리켜야 합니다. 기존 자동 프록시 설정도 선택되어 있다면 업무 네트워크에서 필요한 설정인지 먼저 확인한 뒤 변경 여부를 결정하세요.

Android: VPN 권한과 백그라운드 실행을 따로 확인하세요

Android 클라이언트는 보통 시스템 VPN 인터페이스를 통해 트래픽을 처리합니다. 처음 연결할 때 시스템 VPN 권한 요청이 나타나면 앱 이름을 확인한 뒤 허용하세요. 일반적인 사용에는 대부분 root 권한이 필요하지 않습니다. 데스크톱의 ‘시스템 프록시 설정’ 절차를 Android 클라이언트에 그대로 적용할 수는 없습니다.

1. 실행 중인 다른 VPN을 먼저 종료하세요. 일반적인 개인 설정에서는 활성 VPN 서비스를 한 번에 하나만 사용할 수 있습니다.
2. 클라이언트를 실행하고 시스템 VPN 요청을 허용한 뒤, 시스템 VPN 상태와 클라이언트 연결 상태가 일치하는지 확인하세요.
3. ‘시작하자마자 연결 해제’되는 경우 시스템 설정에서 ‘VPN’을 검색해 다른 앱의 ‘항상 켜짐 VPN’이나 VPN 연결 없이 차단 옵션이 활성화되어 있는지 확인하세요.
4. 화면을 잠근 뒤에만 연결이 끊긴다면 앱의 배터리 및 백그라운드 활동 설정을 확인하세요. 기기마다 메뉴가 다르므로 모든 앱을 제한 없음으로 바꾸지 마세요.

브라우저는 되는데 특정 앱만 연결되지 않는다면 앱별 프록시 목록을 확인하세요. 해당 앱이 제외되어 있거나 ‘선택한 앱만 프록시 사용’ 모드에 포함되지 않았을 수 있습니다. 이 경우 구독이 만료됐다고 먼저 단정할 필요는 없습니다.

포트 충돌: 사용 중인 프로세스를 찾은 뒤 mixed-port 변경하기

로그에 address already in use 또는 포트 바인딩 실패가 표시되면 먼저 해당 포트를 사용 중인 프로세스를 찾으세요. 이전 클라이언트가 완전히 종료되지 않았거나, 백그라운드 서비스가 실행 중이거나, 다른 도구가 같은 포트를 사용하는 경우가 흔합니다. 창을 닫아도 백그라운드 프로세스가 종료된 것은 아닐 수 있습니다.

아래에서는 7890을 점검 예시로 사용합니다. 모든 클라이언트의 기본 포트가 이 값인 것은 아닙니다. 현재 설정이나 실행 중인 설정에서 실제 포트를 확인한 뒤 명령의 숫자를 바꾸세요.

로컬 TCP 수신 포트 확인하기

Windows에서는 명령 프롬프트에서 다음을 실행하세요:

netstat -ano -p tcp | findstr LISTENING | findstr ":7890"

결과에서 로컬 주소와 포트를 확인하고 마지막 열의 PID를 기록한 뒤, 작업 관리자의 ‘세부 정보’ 탭에서 프로세스를 확인하세요. 정체를 모르는 시스템 프로세스를 바로 종료하지 마세요.

macOS에서는 터미널에서 다음을 실행하세요:

lsof -nP -iTCP:7890 -sTCP:LISTEN

포트를 사용 중인 프로세스가 이전 프록시 프로그램이라면 해당 프로그램을 정상적으로 종료하는 것이 우선입니다. 포트를 바꾸기로 했다면 mixed-port를 7897로 변경할 수 있지만, 새 포트를 다른 프로세스가 사용 중이지 않은지도 확인하세요. 프록시를 수동 설정한 터미널, 브라우저, 다른 기기에서도 포트를 바꿔야 합니다. 클라이언트가 관리하는 시스템 프록시는 다시 활성화한 뒤 설정을 확인하세요.

혼합 포트와 컨트롤 포트를 혼동하지 마세요

구독 가져오기 실패: 다운로드·파싱·적용 단계를 나눠 확인하기

‘가져오기 실패’는 세 단계에서 발생할 수 있습니다. 클라이언트가 구독 내용을 가져오지 못했거나, 코어가 내용을 파싱하지 못했거나, 설정을 가져왔지만 활성화하지 않은 경우입니다. 먼저 어느 단계의 문제인지 확인한 뒤 다음 조치를 결정하세요. 같은 링크를 반복해서 붙여 넣어도 새로운 단서는 생기지 않습니다.

1단계: 구독 링크에서 내용을 가져올 수 있는지 확인

• 복사한 내용을 확인하세요. 구독 URL 전체만 복사하고 앞뒤 공백과 줄바꿈을 제거하세요. 안내 문구, 계정 페이지 주소, 개별 노드 링크를 전체 설정이 담긴 구독 주소로 사용하지 마세요.
• 응답 상태를 확인하세요. 401은 인증 문제인 경우가 많습니다. 403은 요청이 거부된 상태이므로 서버 안내를 함께 확인해야 합니다. 404라면 주소를 점검하세요. 429가 반환되면 반복 요청을 멈추고 기다리세요.
• 시스템 시간을 확인하세요. 날짜가 크게 어긋나면 HTTPS 인증서 검증에 실패할 수 있습니다. 인증서 검증을 끄지 말고 먼저 시스템 시간을 동기화하세요.
• 가져오는 경로를 확인하세요. 구독 업데이트가 프록시를 거치도록 설정되어 있지만 사용할 설정이 아직 없다면 시작 단계에서 막힐 수 있습니다. 클라이언트에 직접 연결로 업데이트하는 옵션이 있는지 확인하고, 현재 네트워크에서 접속이 허용될 때 테스트하세요.

브라우저에서 주소가 열린다는 사실만으로 해당 브라우저의 접속 경로가 정상이라는 점만 확인할 수 있습니다. 클라이언트는 프록시 설정, 요청 정보, 네트워크 환경이 다를 수 있습니다. 응답이 로그인 페이지나 오류 페이지라면 요청이 성공으로 표시되더라도 코어에서 사용할 수 있는 YAML 설정은 아닙니다.

2단계: 응답 형식이 코어와 호환되는지 확인

개별 노드 URI, 노드 목록, 전체 Clash 설정은 서로 다른 형식입니다. 구독 서비스가 현재 클라이언트에서 지원하는 형식으로 제공하는지 확인하세요. 노드가 mihomo 확장 프로토콜을 사용한다면 화면에 표시된 이름만 보지 말고 실제 실행 중인 코어가 이를 지원하는지도 확인해야 합니다.

YAML 파싱 오류가 발생하면 로그에 표시된 줄 번호와 오류 유형을 기록하세요. 들여쓰기 방식 혼용, 필드 형식 오류, 지원되지 않는 프로토콜 등으로 설정 로드가 실패할 수 있습니다. 모든 필드를 무작정 삭제하지 마세요. 먼저 설정을 백업한 뒤 프로토콜 참고 자료의 코어 설명에서 지원 범위를 확인하세요.

3단계: 가져온 설정이 실제 실행 설정인지 확인

구독 업데이트가 성공하면 현재 설정 표시, 정책 그룹 내용, 최근 로드 로그를 확인하세요. 노드를 하나 직접 선택하고 규칙에서 참조하는 정책 그룹이 실제로 있는지 확인한 다음 대상 웹사이트에 접속하세요. 로그에 특정 프록시 그룹을 찾을 수 없다고 나오면 DNS를 바꾸기보다 그룹 이름이나 규칙 참조부터 수정하세요.

첫 연결 확인: 세 단계로 문제 위치 찾기

데스크톱에서는 로컬 프록시 포트를 먼저 확인하고, 시스템 프록시와 규칙을 차례로 점검하세요. Android에서는 VPN 상태와 앱별 적용 범위부터 확인합니다. 속도 측정은 특정 테스트 대상의 응답만 확인하므로 실제 사용하려는 앱의 접속 결과를 대신할 수 없습니다.

1단계: 로컬 프록시 포트 직접 테스트

데스크톱에서는 다음 명령으로 HTTP 프록시를 직접 지정해 테스트할 수 있습니다. 예시 포트는 7890이며, 현재 접속이 필요하고 정상적으로 서비스되는 주소로 바꾸세요. Windows에서는 curl.exe, macOS에서는 curl을 사용할 수 있습니다.

curl.exe --proxy http://127.0.0.1:7890 --connect-timeout 10 --max-time 20 -I https://clash67.com/

연결이 거부되면 코어가 포트에서 수신 중인지 먼저 확인하세요. 연결은 되지만 시간이 초과되면 노드, 대상 사이트, 규칙을 점검하세요. 이 테스트는 시스템 프록시 설정에 의존하지 않지만 코어의 현재 모드와 라우팅 규칙의 영향을 받습니다. 한 번 성공했다고 모든 앱이나 대상에 접속할 수 있는 것은 아닙니다.

2단계: 앱이 시스템 프록시를 따르는지 확인

프록시를 직접 지정하면 접속되지만 브라우저에서는 실패한다면 시스템 프록시 주소가 127.0.0.1인지, 포트가 일치하는지, 브라우저에 별도의 프록시 설정이 있는지 확인하세요. 명령줄 도구는 시스템 프록시 설정을 읽지 않을 수 있습니다. 필요한 경우 환경 변수를 별도로 설정하거나, 요구 사항이 명확할 때 TUN을 사용하세요.

3단계: 대상 연결에 적용된 규칙 확인

클라이언트의 연결 목록에서 대상 도메인을 찾아 직접 연결, 프록시 그룹, 차단 규칙 중 무엇이 적용됐는지 확인하세요. 접속 중 연결 기록이 전혀 없다면 트래픽이 클라이언트로 들어오는지부터 확인하세요. 기록은 있지만 잘못된 정책이 선택됐다면 규칙 순서나 정책 그룹 선택을 점검하세요. 로그에서 도메인 확인 실패가 명시된 경우에만 DNS를 확인하고, 모든 연결 문제를 DNS 탓으로 돌리지 마세요.

TUN이 필요하다면 별도로 켠 뒤 같은 테스트를 반복하세요. TUN의 적용 범위는 라우팅, 제외 항목, 앱별 설정, 플랫폼 제한의 영향을 받으므로 모든 연결이 자동으로 처리되는 것은 아닙니다. 문제가 생기면 이미 확인된 상태로 돌아갈 수 있도록 TUN부터 끄고 여러 설정을 한꺼번에 바꾸지 마세요.

종료와 복구: 되돌릴 수 있도록 설정 기록 남기기

초기 설정을 마친 뒤 클라이언트와 코어 버전, 프록시 포트, 활성 설정 이름, 시스템 프록시 및 TUN 상태를 기록하세요. 도움을 요청할 때 운영체제 버전, 관련된 첫 번째 오류, 재현 절차를 함께 제공하면 ‘인터넷이 안 된다’고만 설명하는 것보다 원인을 찾기 쉽습니다.

• 종료 후 인터넷이 끊김: 시스템 프록시가 중지된 로컬 포트를 계속 가리키는지 확인하세요. 클라이언트가 설정한 프록시라면 클라이언트를 다시 실행해 시스템 프록시를 끈 다음 정상적으로 종료하세요.
• TUN을 끈 뒤에도 문제가 계속됨: 다른 VPN이 실행 중인지 확인하고 시스템 네트워크 상태를 점검하세요. 필요하면 로그를 저장한 뒤 클라이언트나 기기를 다시 시작하세요. 알 수 없는 네트워크 인터페이스를 바로 삭제하지 마세요.
• 구독 업데이트 후 작동하지 않음: 업데이트 전후의 노드와 그룹 이름, 규칙 참조를 비교하고 로컬 덮어쓰기 설정이 여전히 유효한지 확인하세요.
• DNS를 더 조정하려는 경우: 먼저 현재 작동하는 설정을 저장한 다음 시작 가이드의 Fake-IP 설명을 읽고 한 번에 한 항목씩 변경하세요.

마지막으로 네 가지를 확인하세요. 코어가 정상적으로 실행 중인지, 올바른 설정이 활성화됐는지, 트래픽이 예상한 경로로 들어오는지, 대상 연결에 예상한 규칙이 적용되는지 확인합니다. 네 항목을 모두 확인한 뒤 시작 프로그램 등록이나 LAN 공유 같은 기능을 추가하면 이후 관리가 쉬워집니다.