Clash 첫 실행 점검 가이드: 혼합 포트, 아웃바운드 모드, 시스템 프록시 확인

1. 설정과 코어가 실행 중인지 먼저 확인

Clash 클라이언트 창이 열렸다고 해서 프록시 코어까지 실행 중인 것은 아닙니다. 처음 설정할 때는 설정이 정상적으로 로드됐는지, 로컬 포트가 수신 대기 중인지, 아웃바운드 정책을 사용할 수 있는지, 대상 앱이 실제로 연결을 프록시에 전달하는지 각각 확인해야 합니다. 이 순서대로 점검하면 포트 문제를 구독 오류로 오인하지 않을 수 있습니다.

이 글에서는 데스크톱에서 흔히 사용하는 HTTP/SOCKS 혼합 포트 7890을 예로 듭니다. 모든 클라이언트의 고정 기본값은 아닙니다. ClashX, Clash Verge Rev 및 mihomo 코어를 사용하는 다른 클라이언트는 설정 위치와 덮어쓰기 방식이 다를 수 있으므로, 현재 클라이언트에 표시되는 유효 설정과 시작 로그를 기준으로 확인하세요.

1. 클라이언트의 「설정」 또는 「Profiles」에서 구독을 다운로드하기만 한 것이 아니라 설정 하나를 선택했는지 확인하세요.
2. 「프록시」 또는 「Proxies」에서 선택할 수 있는 프록시 노드와 정책 그룹이 있는지 확인하세요. DIRECT만 표시된다고 해서 프록시 구독이 정상 적용된 것은 아닙니다.
3. 「로그」 또는 「Logs」를 열어 설정 파싱 결과와 수신 대기 주소를 확인하고, 시작 실패나 포트 바인딩 실패가 기록됐는지 살펴보세요.
4. 현재 사용 중인 코어 종류, 혼합 포트, 실행 모드, 시스템 프록시 상태를 기록하세요. 이후에는 한 번에 하나씩만 변경합니다.

2. 혼합 포트: 수신 대기 주소와 점유 프로세스 확인

mixed-port를 사용하면 HTTP 프록시와 SOCKS 프록시가 하나의 로컬 포트를 함께 사용할 수 있습니다. 브라우저의 수동 HTTP 프록시 주소로 지정할 수 있고, SOCKS5를 지원하는 프로그램도 이 포트를 사용할 수 있습니다. 여기서 ‘혼합’은 시스템의 모든 트래픽을 자동으로 가로챈다는 뜻이 아니며, 컴퓨터의 모든 앱이 프록시를 사용한다는 의미도 아닙니다.

아래는 각 항목의 의미를 이해하기 위한 최소 설정 예시이며, 그대로 인터넷에 연결할 수 있는 완전한 구독 설정은 아닙니다. 기존 설정에 같은 최상위 키를 중복으로 추가하지 마세요. 클라이언트가 덮어쓰기 설정으로 최종 구성을 생성한다면 구독 업데이트 시 덮어써지는 캐시 파일이 아니라 해당 덮어쓰기 메뉴에서 수정해야 합니다.

mixed-port: 7890
allow-lan: false
mode: rule
log-level: info

로컬에서만 사용할 경우 먼저 allow-lan: false로 유지하세요. 로그에 표시된 수신 대기 주소가 127.0.0.1:7890과 같은 루프백 주소인지 확인합니다. 실제 바인딩은 클라이언트와 코어 설정의 영향을 받으므로, 스위치 하나만 보고 수신 범위를 단정하지 마세요.

Windows: 프로세스 ID로 포트를 사용하는 프로세스 확인

PowerShell에서 아래 명령을 실행하세요. 첫 번째 명령은 TCP 7890을 수신 대기 중인 프로세스 ID를 찾고, 두 번째 명령은 해당 ID를 프로세스 이름과 연결해 확인합니다. 예시 ID 1234를 실제 값으로 바꾼 뒤 실행하세요.

Get-NetTCPConnection -LocalPort 7890 -State Listen |
  Select-Object LocalAddress, LocalPort, OwningProcess

Get-Process -Id 1234

포트를 다른 프록시 프로그램이 사용 중이라면 해당 프로그램을 정상 종료하거나 현재 클라이언트에 사용 가능한 포트를 지정하세요. 정체를 모르는 시스템 프로세스를 강제 종료하지 마세요. 포트를 7891로 바꾸면 시스템 프록시, 브라우저별 설정, 명령줄 테스트에서도 같은 포트로 변경해야 합니다.

macOS 및 Linux: 창 표시 여부가 아니라 실제 수신 대기 상태 확인

# macOS: TCP 7890을 수신 대기 중인 프로세스 표시
lsof -nP -iTCP:7890 -sTCP:LISTEN

# Linux: TCP 7890의 수신 대기 소켓 표시
ss -ltnp 'sport = :7890'

프로세스 정보를 확인하려면 해당 권한이 필요할 수 있습니다. 수신 대기 상태가 확인되지 않고 로그에 address already in use가 표시되면 실제로 충돌한 포트를 확인하세요. 설정 파싱 실패가 기록됐다면 설정 파일로 돌아가 오류를 먼저 찾아야 합니다. 웹페이지가 열리지 않는다고 노드를 계속 바꿔도 코어가 포트를 수신 대기하지 않는 문제는 해결되지 않습니다.

3. 아웃바운드 모드: 규칙·전역·직결 동작을 각각 확인

모드는 ‘코어에 들어온 연결을 어떤 아웃바운드로 보낼지’를 제어하고, 시스템 프록시는 ‘앱이 연결을 코어로 보낼지’를 제어합니다. 서로 독립된 설정입니다. 전역 모드를 선택해도 시스템 프록시를 따르지 않고 TUN으로도 처리되지 않는 앱은 여전히 직접 인터넷에 연결할 수 있습니다.

1. 먼저 규칙 모드를 사용하고, 실제로 적용되는 정책 그룹에서 특정 노드를 하나 선택하세요. 자동 선택으로 생기는 변수를 일시적으로 줄일 수 있습니다.
2. 대상 웹사이트를 열고 「연결」에서 도메인, 적용된 규칙, 아웃바운드 경로를 확인하세요. DIRECT가 표시되면 먼저 규칙 설계에 맞는 결과인지 판단해야 합니다.
3. 규칙의 영향을 배제해야 한다면 잠시 전역 모드로 전환하고, 전역 정책에서 직결을 선택하지 않았는지 확인하세요. 테스트가 끝나면 규칙 모드로 되돌립니다.

노드 지연 시간 테스트가 성공했다는 것은 해당 탐지 조건에서 응답을 받을 수 있었다는 뜻일 뿐, 모든 웹사이트·UDP·앱 프로토콜이 정상이라는 의미는 아닙니다. 특정 웹사이트만 실패한다면 해당 연결의 로그를 확인하세요. 지연 시간 숫자만으로 구독 전체가 작동하지 않는다고 판단해서는 안 됩니다.

4. 데스크톱 시스템 프록시: 스위치와 실제 주소 함께 확인

시스템 프록시는 보통 해당 설정을 지원하는 앱에 HTTP 프록시 주소를 제공합니다. 전체 네트워크를 터널링하는 기능은 아닙니다. 첫 테스트에서는 TUN을 끄고 시스템 프록시 경로만 확인하세요. 브라우저 프록시 확장 프로그램, 다른 VPN, TUN을 동시에 사용하면 연결 경로를 파악하기 어려워집니다.

Windows 11

「설정」→「네트워크 및 인터넷」→「프록시」에서 「프록시 서버 사용」을 확인하세요. 클라이언트에서 시스템 프록시를 켠 뒤 주소와 포트가 실제 수신 대기 주소와 일치하는지 확인합니다. 예를 들어 127.0.0.1과 7890을 사용할 수 있습니다. 「설정 스크립트 사용」도 켜져 있다면 PAC 스크립트가 프록시 선택에 관여하는지 확인해 수동 프록시 설정의 결과와 혼동하지 않도록 하세요.

일부 앱은 별도의 프록시 설정이나 WinHTTP 구성을 사용하므로 여기의 설정을 따르지 않을 수 있습니다. netsh winhttp show proxy 명령은 WinHTTP 프록시를 표시하며, Windows 설정에서 현재 사용자가 지정한 프록시를 그대로 보여주는 것은 아닙니다. 두 설정이 다르다고 해서 무작정 초기화하지 마세요.

macOS

최신 macOS에서는 「시스템 설정」→「네트워크」→ 현재 연결된 서비스 →「세부사항」→「프록시」로 이동하세요. 웹 프록시(HTTP), 보안 웹 프록시(HTTPS), 필요한 경우 SOCKS 프록시 주소와 포트를 확인합니다. ClashX 메뉴 막대의 시스템 프록시 설정과 현재 네트워크 서비스의 설정도 함께 대조하세요.

scutil --proxy 명령으로 현재 프록시 정보를 확인할 수 있습니다. HTTP와 HTTPS 프록시 모두 혼합 포트를 가리키는 설정은 흔히 사용됩니다. 여기서 HTTPS 프록시는 일반적으로 HTTP CONNECT를 통해 터널을 만드는 설정이므로 로컬 프록시 주소를 https://127.0.0.1:7890으로 입력할 필요는 없습니다.

Linux 데스크톱

GNOME을 예로 들면 「설정」→「네트워크」→「네트워크 프록시」에서 수동 모드를 선택한 뒤 HTTP, HTTPS, SOCKS의 주소와 포트를 확인합니다. 다른 데스크톱 환경은 설정 위치가 다를 수 있으며, 모든 프로그램이 데스크톱 프록시 설정을 읽는 것은 아닙니다. 터미널에서 사용하는 HTTP_PROXY, HTTPS_PROXY, ALL_PROXY 환경 변수도 명령줄 프로그램에 별도로 영향을 줄 수 있습니다.

5. Android, iOS, TUN: 트래픽 처리 범위 확인

모바일 기기는 보통 시스템 VPN 인터페이스로 트래픽을 처리하므로, 데스크톱에서 ‘시스템 HTTP 프록시 켜기’를 확인하는 방법을 그대로 적용할 수 없습니다. Android 클라이언트는 처음 연결할 때 대개 VPN 연결 권한을 요청하고, iOS 클라이언트는 VPN 구성을 추가해도 되는지 물을 수 있습니다. 방금 설치해 직접 실행 중인 클라이언트에서 보낸 요청인지 확인한 뒤에만 허용하세요.

• Android: VPN 서비스가 실행 중인지 확인한 뒤 앱별 프록시, 앱 우회 또는 지정한 앱만 프록시하는 설정이 켜져 있는지 살펴보세요. 앱이 제외되어 있으면 클라이언트에 연결됨으로 표시돼도 해당 앱의 트래픽은 예상한 프록시 경로를 거치지 않습니다.
• iOS: 「설정」→「일반」→「VPN 및 기기 관리」→「VPN」에서 현재 연결 상태를 확인하세요. 정책 그룹, 규칙, 로그는 클라이언트에서 확인해야 합니다.
• 데스크톱 TUN: 서비스 모드, 관리자 권한 또는 해당 시스템의 승인이 필요한 경우가 많습니다. 스위치 색상만 보지 말고 클라이언트 로그에서 가상 인터페이스 생성과 경로 설정이 성공했는지 확인하세요.
• 다른 VPN: 모바일 운영체제에서는 일반적으로 VPN 서비스를 동시에 여러 개 실행할 수 없습니다. 업무용 프로필, 기업 관리, 앱별 VPN에는 별도 규칙이 적용될 수 있으므로 전환하기 전에 기기의 관리 정책을 확인하세요.

TUN으로 IP 트래픽을 처리하더라도 라우팅, DNS, 앱 제외 설정을 함께 고려해야 합니다. Fake-IP를 사용한다면 DNS 요청이 적절한 해석 경로로 전달되어야 하며, 가상 주소와 관련된 트래픽도 코어로 돌아와 처리되어야 합니다. 앱 하나를 고치기 위해 시스템 DNS, Fake-IP, 라우팅 규칙, MTU를 한꺼번에 변경하지 마세요.

시스템 프록시는 작동하지만 TUN이 작동하지 않는다면 권한, 가상 인터페이스, 라우팅 충돌, DNS를 먼저 확인하세요. TUN은 작동하지만 브라우저의 수동 프록시가 실패한다면 로컬 수신 대기 상태와 브라우저 설정을 우선 살펴보세요. 이렇게 계층별로 비교하는 편이 모든 구성 요소를 동시에 다시 설치하는 것보다 효과적입니다.

6. 방화벽 허용: 로컬 접속과 LAN 공유 구분

로컬 브라우저에서 127.0.0.1:7890에 접속하는 것과 휴대폰에서 LAN을 통해 컴퓨터 프록시에 접속하는 것은 서로 다른 상황입니다. 전자의 경우 프록시 문제를 해결한다며 외부에서 들어오는 포트를 추가로 열 필요가 없습니다. 후자는 클라이언트에서 LAN 연결을 허용하고 적절한 주소에 바인딩해야 하며, 방화벽에서도 신뢰할 수 있는 네트워크의 접속을 허용해야 합니다.

1. 먼저 컴퓨터 자체에서만 테스트하고 LAN 공유는 꺼 두어 네트워크 격리와 인바운드 규칙의 영향을 배제하세요.
2. 공유가 꼭 필요하다면 휴대폰과 컴퓨터가 서로 접속할 수 있는 같은 네트워크에 있는지 확인한 뒤 컴퓨터의 LAN 주소를 사용하세요. 휴대폰에서 127.0.0.1은 컴퓨터가 아니라 휴대폰 자신을 가리킵니다.
3. Windows의 「Windows 보안」→「방화벽 및 네트워크 보호」→「방화벽에서 앱 허용」에서 해당 앱을 확인하세요. 실제로 필요한 신뢰할 수 있는 네트워크에서만 허용하고 공용 네트워크까지 함께 열지 마세요.
4. Linux에서 UFW나 다른 방화벽을 사용 중이라면 신뢰할 수 있는 출발지 주소와 필요한 포트만 지정해 규칙을 설정하세요. 방화벽 전체를 끄는 방법을 상시 해결책으로 사용하지 마세요.

보안 소프트웨어가 코어 프로세스의 아웃바운드 연결이나 TUN 드라이버 동작을 차단할 수도 있습니다. 차단 기록에 표시된 실행 파일 경로와 시간을 확인한 뒤 허용 여부를 결정하세요. 포트가 열려 있다고 노드가 작동하거나 도메인이 정상적으로 해석되는 것은 아닙니다. 연결 로그를 확인해야 합니다.

7. 명확한 요청 하나로 동작 확인

브라우저는 기존 연결을 재사용하거나 캐시를 읽고, 확장 프로그램의 프록시를 사용할 수 있습니다. 먼저 로컬 HTTP 프록시 진입점을 확인하려면 터미널에서 아래 명령을 실행하세요. 예시에서는 공개된 문서용 도메인에 접속하며, 특정 프록시 노드의 실제 성능을 나타내지는 않습니다.

# Windows PowerShell: curl.exe 명시적으로 호출
curl.exe --noproxy "" --proxy http://127.0.0.1:7890 --connect-timeout 10 --max-time 20 -I https://example.com

# macOS / Linux
curl --noproxy "" --proxy http://127.0.0.1:7890 --connect-timeout 10 --max-time 20 -I https://example.com

--noproxy ""는 기존 우회 목록 때문에 이번 요청이 프록시를 건너뛰는 것을 방지합니다. 테스트 조건을 일정하게 유지하도록 연결 시간 제한은 10초, 전체 소요 시간 제한은 20초로 설정합니다. 응답 헤더를 받으면 이번 요청 경로에서 응답이 있었다는 뜻입니다. 그래도 클라이언트에서 프록시 노드와 직결 중 어느 쪽이 선택됐는지 확인해야 합니다. 200 Connection established만 표시됐다고 해서 이후 TLS 연결과 대상 서버의 HTTP 응답까지 완료된 것은 아닙니다.

재현 가능한 점검 기록 남기기

마지막으로 클라이언트 및 코어 버전, 운영체제 버전, 포트, 모드, 정책 그룹 선택, 테스트 시간을 기록하세요. 추가 지원이 필요하면 전체 로그보다 해당 시간대의 오류 줄을 제공하는 편이 문제를 찾기 쉽습니다. 스크린샷을 공개하기 전에는 구독 주소, 토큰, 노드 인증 정보, 개인 네트워크 정보를 가리세요.

• 설정이 정상적으로 로드됐고 로컬 혼합 포트를 수신 대기하는 프로세스를 확인했습니다.
• 규칙 모드에서 대상 연결에 적용된 규칙과 아웃바운드 정책을 설명할 수 있습니다.
• 시스템 프록시와 VPN/TUN 중 어떤 방식으로 트래픽을 처리하는지 확인했으며, 둘을 하나의 스위치로 혼동하지 않습니다.
• 방화벽 허용 범위가 실제 필요에 맞고, 클라이언트를 종료해도 작동하지 않는 프록시가 남지 않습니다.

네 가지 항목을 확인한 뒤 자동 선택, LAN 공유, 복잡한 TUN 설정을 단계적으로 켜세요. 설치와 구독 설정이 더 필요하다면 첫 설정 안내를 참고하고, 용어는 용어집에서 확인하세요.