Clash 첫 설치 후 초기 설정: 시스템 프록시, 혼합 포트 충돌, 시작 프로그램 설정

첫 실행: 설정, 코어, 연결 경로부터 확인

Clash 클라이언트 창이 열렸다고 프록시 연결까지 완료된 것은 아닙니다. 연결이 제대로 작동하려면 클라이언트가 설정을 불러오고, 코어가 로컬 포트를 열고, 앱이 코어로 연결을 전달하며, 규칙이 사용 가능한 출구를 선택해야 합니다. 처음 설정할 때는 이 순서대로 하나씩 점검하세요. 시스템 프록시와 TUN, 여러 네트워크 도구를 한꺼번에 켜고 웹페이지를 새로 고치며 원인을 추측하지 마세요.

이 글은 데스크톱 Clash 계열 클라이언트와 Clash Meta(mihomo) 코어를 사용하는 클라이언트를 중심으로 설명하고, Android와 iOS의 차이도 덧붙입니다. 클라이언트마다 메뉴 이름은 다를 수 있습니다. 시스템 프록시, 규칙 모드, 가상 네트워크 인터페이스는 서로 다른 기능 계층이므로 데스크톱의 스위치 위치를 모바일에 그대로 적용하면 안 됩니다.

1. 설정 불러오기: 클라이언트의 구독 또는 설정 화면에서 서비스 제공자가 제공한 호환 설정을 가져온 뒤, 업데이트가 완료되면 현재 설정으로 선택합니다. 목록에 파일이 표시된다고 해서 활성화된 것은 아닙니다.
2. 코어 로그 확인: YAML 파싱 오류, 존재하지 않는 프록시 그룹 참조, 포트 바인딩 실패가 없는지 확인합니다. 로그에 오류가 계속 표시되면 시스템 네트워크를 바꾸기 전에 설정부터 수정하세요.
3. 규칙 모드 선택: 처음 사용할 때는 설정에 원래 지정된 규칙 모드를 유지하는 것이 좋습니다. 전역 모드는 연결을 전역 정책에 전달할 뿐, 잘못된 노드 매개변수를 고쳐 주지는 않습니다.
4. 프록시 그룹 확인: 그룹을 직접 선택하는 방식이라면 사용 가능한 노드를 선택해야 합니다. DIRECT를 선택하면 해당 트래픽은 프록시를 거치지 않습니다. 지연 시간 테스트에 성공해도 테스트 대상에 연결할 수 있다는 뜻일 뿐, 모든 사이트에 접속할 수 있다는 보장은 아닙니다.

시스템 프록시: 어떤 앱이 로컬 포트를 사용할지 결정

데스크톱 클라이언트의 ‘시스템 프록시’는 일반적으로 운영체제의 프록시 설정을 변경해 해당 설정을 따르는 앱이 로컬 주소(예: 127.0.0.1:7890)를 사용하도록 합니다. 모든 네트워크 연결을 가로채는 기능은 아닙니다. 일부 게임, 명령줄 도구, 별도로 프록시를 설정한 브라우저, 특정 UDP 트래픽은 이 스위치만으로 프록시를 사용하지 않습니다.

Windows: 시스템 트레이 아이콘뿐 아니라 프록시 주소도 확인

Windows 11에서 ‘설정’ → ‘네트워크 및 인터넷’ → ‘프록시’를 열고 ‘수동 프록시 설정’의 주소와 포트가 클라이언트 설정과 일치하는지 확인하세요. 클라이언트에 따라 시스템 프록시를 설정하는 방식이 다를 수 있으므로, 안내 문서와 현재 적용된 설정을 기준으로 확인해야 합니다. 일반 데스크톱 앱의 시스템 프록시와 WinHTTP 설정은 별개이므로 브라우저 문제를 해결하려고 WinHTTP를 함부로 변경하지 마세요.

macOS: 현재 사용 중인 네트워크 서비스 확인

macOS에서 ‘시스템 설정’ → ‘네트워크’ → 현재 네트워크 서비스 → ‘세부사항’ → ‘프록시’로 이동하세요. 웹 프록시, 보안 웹 프록시 또는 SOCKS 프록시가 이전 포트를 가리키고 있지 않은지 확인합니다. Wi-Fi와 유선 네트워크의 설정은 서로 다를 수 있습니다. 네트워크를 바꾼 뒤 문제가 생겼다면 이전 Wi-Fi가 아니라 현재 네트워크 서비스를 점검하세요.

Linux: 데스크톱 환경과 터미널을 따로 확인

Linux의 데스크톱 프록시 설정은 데스크톱 환경과 앱의 구현 방식에 따라 달라집니다. 터미널 프로그램은 보통 프록시 매개변수나 환경 변수를 직접 지정해야 합니다. 브라우저가 프록시를 사용한다고 해서 터미널도 연결된 것은 아닙니다. 아래 두 명령어는 동일한 혼합 포트를 통해 HTTP 프록시와 SOCKS5 프록시를 각각 테스트합니다.

curl -I --proxy http://127.0.0.1:7890 https://example.com
curl -I --proxy socks5h://127.0.0.1:7890 https://example.com

socks5h는 대상 도메인의 이름 확인을 프록시에 맡깁니다. 대상 사이트의 HTTP 응답을 받으면 해당 요청에서 연결 및 응답 과정이 적어도 완료된 것입니다. 시간 초과, 프록시 인증 오류, TLS 오류는 각각 구분해 확인해야 합니다. 이 테스트만으로 모든 앱이 프록시를 사용하거나 로컬 DNS 설정이 올바르다고 판단할 수는 없습니다.

mixed-port: 7890은 자주 쓰이는 포트일 뿐, 고정값은 아닙니다

mixed-port는 HTTP 프록시와 SOCKS 프록시가 같은 수신 포트를 사용하도록 합니다. 이 포트는 로컬 연결 지점이며 원격 노드 포트나 코어 제어 API 포트가 아닙니다. 흔히 7890을 사용하지만 클라이언트와 설정에 따라 다른 값을 사용할 수 있으므로 현재 적용된 설정과 실행 로그를 확인하세요.

포트를 사용 중인 프로세스 확인 방법

로그에 address already in use 또는 바인딩 실패가 표시되면 먼저 포트를 사용 중인 프로세스를 확인하세요. 다른 프록시 클라이언트, 종료되지 않은 이전 코어 프로세스, 개발 서버가 같은 포트를 사용하고 있을 수 있습니다. 아래 명령어의 7890을 오류가 발생한 포트로 바꾸세요.

# Windows: 명령 프롬프트에서 실행합니다. 결과의 마지막 열은 PID입니다
netstat -ano | findstr :7890

# macOS: TCP 수신 프로세스 확인
lsof -nP -iTCP:7890 -sTCP:LISTEN

# Linux: TCP 수신 상태와 프로세스 정보 확인
ss -ltnp 'sport = :7890'

Windows 결과에는 원격 포트 번호가 같은 연결도 포함될 수 있으므로 로컬 주소 열과 LISTENING 상태를 함께 확인하세요. Linux에서 프로세스 이름이 표시되지 않는다면 추가 권한이 필요할 수 있습니다. 프로세스가 무엇인지 확인한 뒤에는 해당 프로그램을 정상적으로 종료하는 것이 우선입니다. PID만 보고 강제 종료하지 마세요.

포트를 17890으로 바꾸면 앱 설정도 함께 변경

충돌을 피하기 위해 포트를 변경해야 한다면 혼합 포트를 17890으로 설정할 수 있습니다. 아래는 확인해야 할 항목만 보여 주는 예시이며, 노드와 규칙을 포함한 완전한 설정 파일은 아닙니다.

mixed-port: 17890
allow-lan: false
mode: rule

변경한 뒤 설정을 다시 불러오고 새 포트가 수신 중인지 확인하세요. 그런 다음 클라이언트의 시스템 프록시를 껐다가 다시 켭니다. 브라우저, 터미널, 다운로드 도구에 프록시를 직접 입력했다면 해당 설정도 변경해야 합니다. 일부 그래픽 클라이언트는 자체 포트 설정으로 구독 항목을 덮어쓸 수 있습니다. 이 경우 클라이언트 설정이나 지원되는 재정의 설정에서 포트를 바꾸지 않으면 구독을 업데이트한 뒤 이전 값으로 돌아갈 수 있습니다.

TUN 및 권한 설정: 일반 프록시부터 확인한 뒤 적용 범위 확장

TUN 모드는 가상 네트워크 인터페이스와 라우팅을 통해 트래픽을 처리하므로 시스템 프록시를 따르지 않는 앱에 유용합니다. 그렇다고 ‘더 고급 기능이니 반드시 켜야 하는’ 옵션은 아닙니다. 데스크톱에서 처음 설정할 때는 먼저 프록시를 직접 지정한 요청으로 노드와 로컬 포트가 정상 작동하는지 확인하세요. 그다음 필요에 따라 TUN을 활성화하면 노드 문제와 라우팅 문제를 구분하기 쉽습니다.

• Windows: 가상 네트워크 어댑터 생성이나 경로 추가에는 보통 권한 상승이 필요하며, 클라이언트가 서비스 모드로 처리할 수 있습니다. 서비스 설치에 실패하면 먼저 로그를 확인하세요. 모든 프로그램을 항상 관리자 권한으로 실행하지는 마세요.
• macOS: 시스템 프록시 변경, 보조 서비스, 네트워크 확장에는 서로 다른 권한 요청이 표시될 수 있습니다. 출처가 명확하고 현재 작업에 필요한 요청에만 권한을 허용하세요. 클라이언트가 시작되지 않으면 보조 서비스 상태를 확인합니다.
• Linux: TUN 장치 생성과 라우팅 변경에는 네트워크 관리 권한이 필요하며, 서비스나 capability 설정으로 권한을 부여할 수 있습니다. 사용하는 클라이언트의 안내를 따르세요. 데스크톱 프록시가 한 번 작동했다고 해서 TUN에 필요한 권한도 갖춰졌다고 볼 수는 없습니다.
• Android: 일반적으로 클라이언트가 시스템 VPN 인터페이스로 트래픽을 처리하므로 VPN 연결 권한을 확인해야 합니다. 데스크톱의 시스템 HTTP 프록시 스위치와는 다릅니다. 다른 VPN 앱이 같은 시스템 연결을 사용 중일 수도 있습니다.
• iOS: 해당 설정을 지원하는 클라이언트를 사용하고 VPN 설정 권한을 확인하세요. 데스크톱용 Clash 설치 파일은 iOS에서 사용할 수 없습니다. 설정 형식과 기능 지원 여부도 사용하는 클라이언트에 맞춰 확인해야 합니다.

TUN을 켠 뒤 LAN 기기, 사내 네트워크 또는 다른 VPN에 문제가 생기면 먼저 TUN을 끄고 정상화되는지 확인한 다음 경로 제외 항목과 DNS 설정을 살펴보세요. 출처를 모르는 DNS 설정을 그대로 복사하지 마세요. 사내 도메인, 라우터 도메인, 일반 공개 도메인은 서로 다른 경로로 이름을 확인할 수 있습니다. 트래픽 처리 방식을 더 알아보려면 기술 참고 자료를 확인하세요.

시작 프로그램 설정: 클라이언트 자동 실행, 코어 실행, 프록시 복구는 별개입니다

‘시작 프로그램’은 보통 사용자가 로그인한 뒤 클라이언트를 실행한다는 뜻입니다. 로그인 전부터 프록시 서비스가 실행된다는 의미는 아니며, 실행 후 올바른 설정을 불러오거나 시스템 프록시를 복구하거나 TUN을 켠다는 보장도 없습니다. 처음 확인할 때는 설정 스위치가 켜져 있는지만 보지 말고 클라이언트를 완전히 종료한 뒤 다시 로그인하거나 기기를 재시작해 테스트하세요.

1. 클라이언트 자동 실행 설정: 클라이언트의 시작 설정에서 해당 옵션을 켜고, 프로그램을 계속 사용할 위치에 옮겼는지 확인하세요. 임시 압축 해제 폴더, 디스크 이미지, 삭제할 설치 폴더에서 실행하지 마세요.
2. 시스템 시작 항목 확인: Windows 11에서는 ‘설정’ → ‘앱’ → ‘시작 프로그램’에서 확인할 수 있습니다. macOS에서는 ‘시스템 설정’ → ‘일반’ → ‘로그인 항목 및 확장 프로그램’을 확인하세요. Linux에서는 사용 중인 데스크톱 환경의 자동 시작 앱이나 해당 서비스를 확인합니다.
3. 시작 후 실제 상태 확인: 현재 설정이 계속 선택되어 있는지, 프록시 그룹이 원하는 항목으로 복원되었는지, 수신 포트가 올바른지 확인하세요. 시스템 프록시 또는 TUN도 클라이언트 설정에 따라 활성화되었는지 점검합니다.
4. 네트워크 연결 후 구독 업데이트 확인: 로그인 직후에는 Wi-Fi, 포털 인증, 회사 네트워크가 아직 준비되지 않았을 수 있습니다. 이때 자동 업데이트에 실패해도 로컬에 저장된 설정을 사용할 수 없다는 뜻은 아닙니다. 먼저 네트워크를 확인한 뒤 수동으로 업데이트를 다시 시도하세요.

모바일에서는 백그라운드 실행과 배터리 관리도 확인

Android의 백그라운드 제한으로 화면을 잠근 뒤 프록시 서비스가 종료될 수 있습니다. ‘처음에는 되다가 잠시 뒤 연결이 끊기는’ 문제가 생기면 클라이언트가 계속 실행 중인지, 시스템 VPN 상태가 유지되는지, 배터리 관리가 백그라운드 실행을 제한하는지 확인하세요. 필요한 앱에만 설정을 조정하고 기기 전체의 절전 기능을 모두 끌 필요는 없습니다. iOS의 자동 연결 동작은 클라이언트와 시스템 지원 여부에 따라 다르므로 데스크톱과 같은 자동 실행을 보장한다고 볼 수 없습니다.

첫 설치 점검 순서: 로컬 수신부터 앱 연결까지

문제 범위를 좁히려면 계층별로 확인하고, 한 번에 하나씩만 변경하세요. 노드는 정상으로 보이지만 앱에서 접속할 수 없을 때 아래 점검표를 순서대로 확인하면 좋습니다.

클라이언트의 연결 기록을 함께 보면 원인을 더 좁힐 수 있습니다. 대상 요청이 전혀 보이지 않는다면 연결 경로를 확인하세요. 요청은 보이지만 DIRECT로 처리된다면 규칙과 프록시 그룹을 점검합니다. 프록시 출구로 요청이 전달된 뒤 시간 초과가 발생하면 노드 연결 상태와 대상 사이트를 확인하세요. 원인을 찾을 때는 로그 수준을 잠시 높이고, 해결한 뒤에는 평소 설정으로 되돌려 로그가 지나치게 쌓이지 않도록 합니다.