Clash 화면 기능 가이드

프로필·프록시·트래픽 진입 경로 구분하기

Clash 화면을 이해하려면 ‘설정이 어디서 오는지’, ‘요청을 어디서 처리하는지’, ‘앱 트래픽이 클라이언트로 들어오는지’를 나누어 봐야 합니다. 프로필 메뉴에서는 노드, 프록시 그룹, 규칙이 포함된 설정을 불러오고 관리합니다. 프록시 메뉴에서는 그룹을 확인하고 출구를 선택합니다. 시스템 프록시나 TUN은 앱 트래픽을 코어로 전달하는 방식을 결정합니다. 로그 메뉴는 처리 과정과 오류의 단서를 보여 주지만, 앞서 설명한 설정을 대신하지는 않습니다.

Clash는 프록시 코어와 관련 클라이언트를 통칭할 때 흔히 쓰이는 이름이며, mihomo는 Clash Meta에서 발전한 코어입니다. GUI 클라이언트마다 메뉴 이름과 버튼 위치, 코어 기능이 다를 수 있습니다. 아래에서는 기능 위치를 ‘메인 창 → 프로필’, ‘메인 창 → 프록시’처럼 표시합니다. 실제 화면에서는 ‘구독’, ‘Profiles’, ‘Proxies’ 등으로 표시될 수 있으므로 버튼 문구가 완전히 일치하는지 찾기보다 기능을 기준으로 확인하세요.

프로필 메뉴: 가져온 뒤 적용 여부 확인

처음 사용할 때는 ‘메인 창 → 프로필’로 이동한 다음 ‘가져오기’ 또는 ‘새로 만들기’를 선택하세요. 원격 구독을 사용하려면 보통 구독 주소를 입력하고, 로컬 프로필은 YAML 파일을 선택합니다. 구독 주소에는 개인 액세스 정보가 포함될 수 있으므로 안전한 곳에 보관하고 스크린샷이나 공개된 문의 글에 그대로 올리지 마세요.

가져오기·적용·업데이트는 서로 다른 작업입니다

1. 가져오기: 원격 프로필이나 로컬 파일을 목록에 추가합니다. 프로필 카드가 목록에 표시된다는 것은 클라이언트에 해당 프로필 항목이 저장되었다는 뜻입니다.
2. 적용: 프로필을 선택해 코어에 불러옵니다. 선택 표시와 현재 프로필 이름을 확인하고, 로드 실패 메시지가 표시되는지도 살펴보세요.
3. 업데이트: 원격 프로필의 내용을 다시 가져옵니다. 완료 후 업데이트 시간과 로드 결과를 확인하세요. 클라이언트의 다시 불러오기 방식에 따라 프로필을 다시 적용해야 할 수도 있습니다.

예를 들어 구독 업데이트로 노드가 추가됐는데 프록시 메뉴에 이전 목록이 보인다면, 업데이트한 프로필 카드가 적용되지 않은 다른 카드인지 먼저 확인하세요. 적용할 때 YAML 파싱 오류가 발생하면 안내된 줄 번호와 들여쓰기, 필드 형식을 살펴보세요. 업데이트 버튼을 반복해서 누르는 것만으로 해결되지는 않습니다. 네트워크 요청 실패와 프로필 파싱 실패는 서로 다른 문제입니다. 전자는 구독 주소와 네트워크, 서버 응답을 확인하고, 후자는 실제로 받은 내용이 올바른 프로필 형식인지 확인하세요.

로컬 수정과 구독 업데이트의 주의점

원격 프로필의 캐시를 직접 수정하면 다음 업데이트 때 변경 내용이 덮어써질 수 있습니다. 클라이언트에서 ‘오버라이드’, ‘병합’, ‘확장 스크립트’를 지원한다면 실행 순서를 먼저 확인하고, 계속 유지할 로컬 규칙은 해당 기능에 추가하세요. 오버라이드 형식은 클라이언트마다 다릅니다. 특정 클라이언트의 스크립트를 mihomo YAML 필드로 그대로 사용할 수는 없습니다.

프록시 메뉴: 모드를 확인한 다음 그룹 살펴보기

‘메인 창 → 프록시’로 이동했을 때 화면의 각 상자를 모두 서버 한 대로 보면 안 됩니다. 보통 프록시 그룹이 먼저 표시되고, 각 그룹 안에 선택 가능한 노드나 다른 프록시 그룹이 나옵니다. 규칙이 특정 그룹을 지정했다면 실제 출구는 그룹 유형과 현재 선택에 따라 달라집니다. 따라서 노드를 눌렀더라도 규칙에 일치하는 트래픽이 해당 그룹으로 전달되는지 확인해야 합니다.

세 가지 모드에 따른 트래픽 처리

• 규칙 모드: 프로필의 규칙을 순서대로 적용해 요청을 직접 연결하거나 프록시로 보내고, 차단할 수 있습니다. 프록시 그룹을 선택했더라도 해당 그룹과 일치하는 트래픽만 그룹을 사용합니다.
• 전역 모드: 코어로 들어온 요청을 전역 정책에 따라 처리합니다. 잠시 비교하며 문제를 찾을 때 유용하지만, 코어에 들어오지 않은 앱 트래픽까지 자동으로 프록시를 사용하게 하지는 않습니다.
• 직접 연결 모드: 코어로 들어온 연결을 직접 연결합니다. 일부 클라이언트에는 별도의 버튼이 없으므로 실제 지원 여부를 확인하세요.

수동 선택과 자동 정책의 차이

select 유형은 직접 선택할 수 있습니다. url-test는 주기적인 테스트 결과에 따라 출구를 선택하고, fallback은 설정된 순서대로 사용 가능한 항목을 선택하며, load-balance는 설정된 정책에 따라 연결을 분산합니다. 자동 정책을 일시적으로 수동 지정할 수 있는지, 자동 선택을 어떻게 복원하는지는 코어와 UI 구현에 따라 다릅니다. 카드 모양만으로 판단하지 마세요.

예를 들어 규칙에서 대상 트래픽을 ‘웹 프록시’ 그룹으로 보내는데 ‘미디어 프록시’ 그룹을 바꾸면 웹 접속 결과는 보통 달라지지 않습니다. 이럴 때는 노드를 계속 무작위로 바꾸기보다 연결 메뉴에서 실제로 일치한 그룹을 확인하세요. 프록시 그룹이 다른 그룹을 참조할 수도 있으므로 최종 노드까지 프록시 체인을 따라가며 살펴봐야 합니다.

지연 시간 테스트: 시간 초과와 실제 다운로드 속도 구분하기

프록시 메뉴의 ‘속도 테스트’는 보통 지정된 테스트 주소에 요청을 보내고 응답을 받기까지 걸린 시간을 밀리초로 표시합니다. 지속적인 다운로드 대역폭 측정이나 네트워크 계층의 ICMP ping과는 다릅니다. 테스트 주소와 시간 초과 기준, 노드 연결 상태, 현재 네트워크 상태에 따라 결과가 달라집니다.

예를 들어 두 번의 테스트 결과가 85 ms와 210 ms라면, 해당 테스트 조건에서 앞의 노드가 더 빠르게 응답했다는 뜻입니다. 읽는 법을 설명하기 위한 예시이며 Clash 내비에서 측정한 결과가 아닙니다. 이 결과만으로 대용량 파일 다운로드 속도나 동영상 재생 안정성, 특정 사이트 접속 가능 여부를 판단할 수 없습니다. timeout이 표시되면 노드 연결 실패인지, 테스트 주소에 접속할 수 없는지, 대기 시간이 너무 짧은지 구분해야 합니다.

1. 먼저 실제로 사용할 노드 하나를 테스트해 결과가 나오는지 확인하세요.
2. 사용할 앱으로 대상 사이트에 접속하고 문제가 발생한 시간을 기록하세요.
3. 연결 메뉴에서 대상 트래픽이 방금 테스트한 노드를 통과하는지 확인한 뒤 같은 시간대의 로그를 살펴보세요.

많은 노드에 연속으로 전체 테스트를 실행하면 추가 연결이 발생합니다. 문제를 찾을 때는 후보를 몇 개만 테스트하면 결과를 비교하기 쉽고, 테스트 요청과 실제 앱 요청이 섞이는 것도 막을 수 있습니다. 화면에서 테스트 주소를 바꿀 수 있다면 주소를 변경한 뒤 새 기준으로 비교하세요. 서로 다른 테스트 조건에서 나온 수치를 그대로 순위 매기지 마세요.

연결 메뉴: 규칙과 최종 출구 확인

‘연결’ 메뉴에서는 ‘이 앱의 트래픽이 실제로 어디로 가는지’를 확인할 수 있습니다. 클라이언트에서 설정을 적용한 상태로 새 접속을 시도한 뒤 도메인, 대상 IP, 프로세스 이름으로 필터링하세요. 프로세스 정보의 표시 여부는 플랫폼 권한, 트래픽 전달 방식, 코어 설정에 따라 달라집니다. 정보가 비어 있어도 연결에 문제가 있다고 단정할 수는 없습니다.

• 대상: 도메인 또는 IP 주소와 대상 포트를 확인하세요. HTTPS에서 흔히 쓰는 대상 포트는 443이며, 클라이언트의 로컬 수신 포트가 아닙니다.
• 규칙: 도메인 접미사 규칙이나 마지막 규칙인 MATCH 등, 일치한 규칙의 유형과 조건을 확인하세요.
• 프록시 체인: 최종 출구가 DIRECT인지, 프록시 그룹과 그 안에서 선택된 노드인지 확인하세요.
• 연결 상태: 연결 시간과 업로드·다운로드 수치를 함께 살펴 요청이 계속 진행 중인지 확인하세요. 클라이언트에 따라 열 이름은 다를 수 있습니다.

정책을 바꿔도 이미 연결된 트래픽이 새 출구로 전환되지 않을 수 있습니다. 브라우저가 기존 연결을 계속 재사용할 수도 있으므로 새 연결을 만든 뒤 확인하세요. 클라이언트에서 ‘연결 닫기’를 지원한다면 해당 항목만 닫고 다시 접속할 수 있습니다. 전체 연결을 닫으면 다운로드나 회의가 중단될 수 있으니 영향을 먼저 확인하세요.

대상이 연결 목록에 계속 표시되지 않는다면 앱이 시스템 프록시를 따르는지, 다른 네트워크 경로를 사용하는지 먼저 확인하세요. 앱 캐시 때문에 이번 작업에서 새 요청이 발생하지 않았을 수도 있습니다. 목록이 비어 있다는 이유만으로 노드가 작동하지 않는다고 판단하지 마세요.

로그 메뉴: 수준별로 오류를 살펴보고 한 줄만으로 판단하지 않기

‘메인 창 → 로그’로 이동한 뒤 화면의 필터 조건을 초기화하거나 현재 시간을 기록하고 문제를 한 번 재현하세요. 로그에는 코어 실행 이벤트와 연결 처리 정보가 기록되지만, 모든 요청의 전체 기록이 저장되는 것은 아닙니다. 일부 클라이언트는 로그 메뉴를 열어야 실시간 기록을 받습니다. 로그를 장기간 보관해야 한다면 클라이언트가 파일 로그를 지원하는지 확인하세요.

자주 나타나는 오류 세 가지

• address already in use: 보통 수신 주소나 포트를 다른 프로세스가 사용 중이라는 뜻입니다. 먼저 해당 포트와 프로세스를 찾아보세요. 구독을 바로 바꿀 필요는 없습니다.
• i/o timeout: 네트워크 작업이 시간 초과되었다는 뜻입니다. 대상 주소와 연결 단계, 주변 로그를 함께 확인해야 하며 구독이 만료되었다는 뜻은 아닙니다.
• connection refused: 대상 포트에서 연결을 수신하지 않거나 연결을 명시적으로 거부할 때 흔히 발생합니다. 오류가 로컬 인터페이스, 상위 노드, 대상 서비스 중 어디를 가리키는지 확인하세요.

프로필의 log-level은 로그 출력 수준을 제어합니다. 로그 메뉴의 드롭다운은 이미 수신된 정보를 필터링하는 기능일 수도 있습니다. 코어에서 오류만 출력하고 있다면 화면 필터를 ‘전체’로 바꿔도 생성되지 않은 일반 로그가 복원되지는 않습니다. 더 자세한 내용을 확인하려면 코어 로그 설정을 수정했는지 확인하고, 다시 로드한 뒤 문제를 재현하세요.

설정 메뉴: 포트·시스템 프록시·TUN을 각각 확인

설정 메뉴의 로컬 포트는 앱이 클라이언트에 연결하는 진입점이고, 컨트롤 포트는 UI나 관리 도구가 코어 인터페이스를 호출하는 데 사용합니다. 두 포트의 용도는 다릅니다. 예를 들어 mixed-port: 7890은 하나의 포트에서 HTTP와 SOCKS 프록시 요청을 모두 받는다는 뜻입니다. 127.0.0.1:9090은 로컬 컨트롤 인터페이스 주소의 예로 흔히 쓰이지만, 모든 클라이언트의 기본값은 아닙니다.

아래 내용은 각 필드의 의미를 보여 주는 예시일 뿐, 구독 프로필을 그대로 대체해 사용할 수 있는 완성된 설정은 아닙니다. GUI 클라이언트에서 설정 메뉴로 이 필드들을 덮어쓸 수 있으므로 실제 적용 값을 먼저 확인하세요.

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

시스템 프록시와 TUN은 별개의 설정입니다

시스템 프록시는 보통 운영체제의 프록시 설정을 변경합니다. 해당 설정을 따르는 앱만 이 경로를 사용합니다. TUN은 가상 네트워크 인터페이스와 라우팅을 통해 트래픽을 전달하며, 더 높은 권한이 필요하고 DNS 및 라우팅 설정에도 영향을 줍니다. TUN을 켠 뒤에도 서비스 권한과 가상 인터페이스 생성 여부, 규칙이 예상대로 설정됐는지 확인하세요. 모든 연결 문제를 해결하는 스위치로 여겨서는 안 됩니다.

매개변수 설정 메뉴를 제공하는 클라이언트에서는 ‘설정 → 매개변수 설정’에서 포트를 찾으세요. 해당 메뉴가 없다면 ‘포트’나 ‘코어 설정’을 확인하면 됩니다. 7890을 변경한 뒤에는 수동으로 설정한 브라우저 프록시, 터미널 환경 변수, 다른 앱의 설정도 함께 변경해야 합니다. 클라이언트가 관리하는 시스템 프록시 설정도 자동으로 업데이트됐는지 운영체제에서 확인하세요.

프로필부터 로그까지 전체 점검하기

‘노드 지연 시간 테스트는 통과하는데 웹페이지가 열리지 않는’ 경우 다음 순서대로 확인하면 여러 설정을 한꺼번에 바꾸지 않고 문제 지점을 좁힐 수 있습니다.

1. 프로필 메뉴: 대상 프로필이 현재 적용되어 있고 로드 오류가 없는지 확인하세요. 구독 업데이트 시간은 단서일 뿐, 프로필 로드 결과를 대신하지 않습니다.
2. 프록시 메뉴: 규칙 모드가 선택되어 있는지 확인하고 대상 프록시 그룹과 노드를 살펴보세요. 비교가 필요할 때만 잠시 전역 모드로 바꾸고 원래 설정을 기록해 두세요.
3. 설정 메뉴: 앱 트래픽이 시스템 프록시나 TUN을 통해 전달되는지 확인하고 실제 수신 포트를 살펴보세요. 앱이 이전 포트인 7890을 계속 사용하지 않는지도 확인해야 합니다.
4. 연결 메뉴: 대상 사이트에 다시 접속해 새 연결이 표시되는지 확인하고 일치한 규칙과 최종 출구를 기록하세요.
5. 로그 메뉴: 같은 시간대의 오류를 살펴보고 DNS, 상위 노드 연결, TLS, 로컬 수신 중 어느 단계에서 발생했는지 구분하세요.
6. 설정 복원: 문제 해결이 끝나면 임시로 바꾼 모드와 로그 수준을 원래대로 되돌리고, 필요한 정보는 민감한 내용을 가린 뒤 보관하세요.

평소에는 ‘프로필 메뉴에서 출처 확인 → 프록시 메뉴에서 정책 확인 → 연결 메뉴에서 결과 확인 → 로그 메뉴에서 오류 분석’ 순서로 살펴보세요. 각 필드의 자세한 의미는 전체 설정 가이드에서 확인할 수 있습니다. 처음 프로필을 가져오고 앱을 연결하는 방법은 빠른 시작 가이드를 따라 진행하세요.