CLASH / LINUX / 설정 참고

Clash 용어 가이드

코어부터 설정 필드와 시스템 서비스까지 배포 단계별로 용어를 찾아보세요. 먼저 ‘트래픽이 코어에 어떻게 들어오는지’와 ‘들어온 뒤 어떻게 분기되는지’를 구분한 다음, 수정할 설정을 확인하세요.

이 페이지에는 용어 24개가 정리되어 있습니다. 각 카드의 주소 앵커를 사용해 개별 항목을 공유할 수 있습니다. 전체 YAML 예시는 설정 참고에서, 첫 배포는 빠른 시작을 참고하세요.

mihomo 구독 mixed-port Fake-IP TUN systemd

CORE / CLIENT

코어와 클라이언트

인터페이스는 관리를, 코어는 연결 처리를 담당합니다. 구독과 노드는 설정 데이터이며 소프트웨어의 실행 상태가 아닙니다.

mihomo 코어: mihomo는 프록시 서버에 연결하고 규칙을 해석하며 DNS를 처리하는 네트워크 프록시 코어입니다. Clash 설정 체계를 이어받아 기능을 확장하고 있습니다. 그래픽 클라이언트로 관리하거나 Linux에서 독립 프로세스로 실행할 수 있습니다. 코어 버전과 그래픽 인터페이스 버전은 서로 다른 개념입니다. 특정 필드의 지원 여부를 확인할 때는 클라이언트의 정보 화면이 아니라 실제 실행 중인 코어 버전을 확인하세요.; mihomo -v

그래픽 클라이언트: 그래픽 클라이언트는 구독 가져오기, 정책 선택, 로그 확인, 서비스 관리를 위한 인터페이스를 제공하며, 보통 백그라운드에서 프록시 코어를 실행합니다. 클라이언트에 저장된 인터페이스 설정이 코어에서 실제로 불러온 설정과 다를 수 있으므로 문제를 해결할 때는 현재 설정과 재정의 항목, 코어 로그를 확인해야 합니다. Clash Verge Rev 또는 FlClash를 선택할 때는 설치 패키지가 지원하는 배포판과 프로세서 아키텍처도 확인하세요.; Linux 클라이언트 보기

구독: 구독은 보통 프록시 노드나 전체 설정을 가져오는 원격 주소이며, 프록시 프로토콜 자체를 뜻하지는 않습니다. 응답에는 노드 목록만 포함될 수도 있고 정책 그룹, DNS, 규칙이 함께 들어갈 수도 있습니다. 가져오기 전에 형식이 호환되는지 확인하고, 구독 주소에는 접근 인증 정보가 포함될 수 있으므로 민감한 정보로 취급하세요. 구독을 갱신하면 로컬 수정 사항이 덮어써질 수 있으므로 계속 유지할 설정은 클라이언트가 지원하는 재정의 기능에 넣으세요.; proxy-providers

노드: 노드는 프록시 서버에 연결하는 데 필요한 설정의 묶음으로, 프로토콜 종류, 서버 주소, 포트, 인증 정보나 전송 옵션을 포함합니다. 노드에 표시되는 이름은 설정에서 참조하는 이름일 뿐이며, 이름만으로 서버 위치나 출구 IP, 사용 가능 여부를 판단할 수 없습니다. 노드를 설정에 추가한 뒤에도 정책 그룹이나 규칙에서 실제로 선택해야 해당 연결에 사용됩니다.; proxies / type / server / port

지연 시간과 상태 확인: 클라이언트에 표시되는 지연 시간은 보통 지정된 테스트 주소에 접속하는 데 걸린 시간이며, 측정에 포함되는 네트워크 구간은 테스트 방식에 따라 달라집니다. 다운로드 대역폭과 같지 않고 모든 웹사이트의 접속 품질을 나타내지도 않습니다. 결과를 비교할 때는 테스트 주소를 통일하고, 시간 초과가 발생하면 로그와 실제 요청을 확인하세요. 상태 확인은 노드 사용 가능 여부를 판별하는 기능입니다. 너무 자주 확인하면 네트워크 요청이 늘고 모바일 기기가 깨어나는 횟수도 증가합니다.; health-check / url / interval

PROTOCOL

프록시 프로토콜

로컬 애플리케이션이 연결하는 프록시 진입점과 코어가 원격 노드에 연결할 때 사용하는 프로토콜은 서로 다른 두 구간입니다.

HTTP 프록시: HTTP 프록시는 애플리케이션이 명시적으로 연결하는 프록시 진입점이며, HTTPS 요청은 보통 CONNECT로 터널을 만듭니다. 진입점이 HTTP 프로토콜을 사용한다고 해서 대상 웹사이트가 HTTP만 지원하는 것은 아닙니다. 브라우저나 명령줄 도구에 올바른 프록시 주소와 포트를 설정해야 합니다. 프록시 주소의 프로토콜 접두사는 애플리케이션이 프록시에 연결하는 방식을 나타냅니다. 대상 URL이 HTTPS라는 이유만으로 HTTPS 프록시 진입점으로 바꾸지 마세요.; http://127.0.0.1:7890

SOCKS5: SOCKS5는 TCP 연결에 사용할 수 있는 범용 프록시 프로토콜이며, 애플리케이션과 서버가 지원하면 UDP도 전달할 수 있습니다. 도메인을 로컬에서 해석할지 프록시 서버에서 해석할지는 애플리케이션 설정에 따라 다릅니다. 예를 들어 curl에서 socks5h 주소를 사용하면 도메인 해석을 프록시 서버에 맡깁니다. SOCKS 진입점을 설정한 뒤 일부 앱만 작동한다면 분기 규칙을 바꾸기 전에 해당 앱의 SOCKS 지원 여부부터 확인하세요.; socks5h://127.0.0.1:7890

Shadowsocks: Shadowsocks는 암호화 프록시 프로토콜로, 설정에는 보통 서버 주소, 포트, 암호화 방식, 비밀번호가 포함됩니다. 이는 코어와 원격 서버 간의 연결 방식을 가리키며 로컬 수신 진입점이 아닙니다. 암호화 방식은 서버와 일치해야 하며 플러그인을 사용하는 경우 양쪽에서 모두 지원해야 합니다. 연결에 실패하면 프로토콜 매개변수와 서버 연결 상태를 각각 확인하고, 로컬 mixed-port를 원격 서버 포트로 입력하지 마세요.; type: ss / cipher / password

Trojan: Trojan은 보통 TLS로 원격 프록시 서버에 연결하며, 설정에는 서버 주소, 포트, 비밀번호, 인증서 관련 매개변수가 포함됩니다. SNI는 TLS 핸드셰이크에서 서버 이름을 전달하는 데 사용되므로 연결 주소와 다를 수 있습니다. 인증서 오류가 발생하면 먼저 도메인, 시스템 시간, 인증서 체인을 확인하세요. 인증서 검증을 끄면 보안 경계가 달라지므로 연결 문제를 해결하기 위한 상시 조치로 사용해서는 안 됩니다.; type: trojan / sni / password

CONFIG.YAML

설정 필드

필드 이름은 원래 표기를 유지하세요. 계층이나 포트, DNS 동작을 수정한 뒤에는 설정을 테스트하고 서비스를 다시 불러오세요.

YAML: YAML은 mihomo 설정 파일에 사용하는 데이터 형식으로, 들여쓰기로 계층을 나타내며 목록 항목은 보통 하이픈으로 시작합니다. 같은 계층의 필드는 들여쓰기 간격을 맞추고, 공백 대신 Tab을 사용하지 마세요. 수정한 뒤에는 설정을 테스트한 후 서비스를 다시 불러오세요. 특수 문자가 포함된 문자열은 따옴표로 묶으면 구독 주소나 비밀번호를 복사할 때 다른 구조로 잘못 해석되는 일을 방지할 수 있습니다.; mihomo -t -d ~/.config/mihomo

mixed-port: mixed-port는 HTTP와 SOCKS를 모두 지원하는 로컬 혼합 프록시 포트를 지정합니다. 애플리케이션은 지원하는 프록시 유형에 맞춰 같은 진입점에 연결할 수 있습니다. 포트가 열려 있다고 모든 애플리케이션이 자동으로 사용하는 것은 아닙니다. 시스템 프록시나 애플리케이션 프록시, 관련 환경 변수를 설정하고 수신 주소도 확인하세요. 7890은 흔히 사용하는 예시일 뿐 필수값이 아닙니다. 포트가 충돌하면 다른 값으로 바꾸고 애플리케이션 설정도 함께 수정하세요.; mixed-port: 7890

external-controller: external-controller는 코어 제어 API의 수신 주소를 지정하며, 대시보드에서 연결을 조회하고 정책을 전환하거나 실행 상태를 조정할 때 사용합니다. 웹 트래픽용 프록시 진입점은 아닙니다. 로컬에서 사용할 때는 루프백 주소에 바인딩하는 것이 좋으며, 원격 관리에는 secret을 설정하고 네트워크 접근 범위를 제한해야 합니다. 대시보드 포트를 시스템 프록시 포트로 잘못 입력하면 코어는 실행되지만 애플리케이션이 제대로 접속하지 못할 수 있습니다.; external-controller: 127.0.0.1:9090

Fake-IP: Fake-IP 모드는 DNS 요청에 내부 매핑용 가상 주소를 반환해, 이후 연결에서 코어가 원래 도메인을 찾도록 합니다. 이 주소는 실제 서버 주소가 아닙니다. 일부 로컬 네트워크 서비스나 특수 애플리케이션은 fake-ip-filter에 추가해야 할 수 있으며, 설정을 변경한 뒤에는 기존 DNS 캐시도 고려하세요. 가상 주소가 보인다고 DNS 조회가 실패한 것은 아닙니다. 이후 연결을 코어가 제대로 받아 원래 도메인으로 복원하는지가 중요합니다.; dns.enhanced-mode / fake-ip-filter

DNS 누수: DNS 누수는 보통 DNS 조회 요청이 예상한 처리 경로를 벗어나는 현상을 말합니다. 예를 들어 연결은 프록시를 거치지만 DNS 조회는 로컬 네트워크의 리졸버로 전송되는 경우입니다. 시스템 DNS, 브라우저 보안 DNS, 앱 내장 DNS, TUN이 처리하는 범위를 함께 확인하세요. 웹페이지가 열리는지만으로 판단해서는 안 됩니다. 앱마다 DNS 경로가 다를 수 있으므로 패킷 캡처나 로그로 실제 목적지 주소와 전송 경로를 확인하세요.; dns / nameserver / dns-hijack

proxy-providers: proxy-providers는 노드 출처를 별도의 참조 가능한 모음으로 분리하며, 정책 그룹은 use로 모음 이름을 참조합니다. HTTP 유형은 interval로 갱신 간격을 설정하고 health-check로 노드 상태를 확인할 수 있습니다. 노드를 제공한다고 해서 rules나 DNS 설정까지 제공하는 것은 아닙니다. 가져오기에 실패하면 다운로드 요청 실패인지 콘텐츠 해석 실패인지 구분하세요. 전자는 네트워크 경로, 후자는 데이터 형식과 관련된 문제입니다.; proxy-providers / use / interval

RULES / POLICY

규칙과 정책 그룹

규칙은 연결을 어디로 보낼지 정하고, 정책 그룹은 어떤 출구를 사용할지 결정합니다. 두 항목은 이름으로 연결됩니다.

규칙 기반 라우팅: 규칙 기반 라우팅은 도메인, 대상 IP, 포트 등의 조건에 따라 연결을 직접 연결하거나 차단하거나 특정 정책으로 보냅니다. 일반 규칙은 위에서부터 순서대로 적용되므로 먼저 일치한 규칙이 우선합니다. 규칙을 조정할 때는 먼저 연결 기록에서 어떤 규칙이 일치했는지 확인한 다음, 순서를 바꾸거나 대상 정책을 수정할지 판단하세요. 마지막의 MATCH는 보통 나머지 트래픽을 처리하는 규칙입니다. 너무 앞에 두면 뒤에 있는 규칙은 일치할 수 없습니다.; rules / DOMAIN-SUFFIX / MATCH

정책 그룹: 정책 그룹은 노드, 내장 정책 또는 다른 그룹을 묶어 규칙에서 참조할 대상으로 만듭니다. select는 수동 선택, url-test는 테스트 결과에 따른 선택, fallback은 사용 가능 여부에 따른 대체에 사용됩니다. 그룹 이름은 규칙에서 참조하는 이름과 일치해야 하며, 그룹 간 참조가 순환하지 않도록 주의하세요. 자동 선택 결과는 테스트 주소, 확인 간격, 허용 오차에 따라서도 달라집니다. 새 연결이 생길 때마다 모든 노드를 다시 측정한다는 뜻은 아닙니다.; proxy-groups / select / url-test / fallback

GeoIP와 GeoSite: GeoIP는 IP 데이터 세트를 기준으로 주소의 위치를 판별하고, GeoSite는 도메인 데이터 세트를 기준으로 사이트를 분류합니다. 실시간 위치 정보가 아니며 모든 CDN이나 새 도메인을 포함한다고 보장할 수 없습니다. 사용하기 전에 데이터 출처와 분류 이름, 코어 지원 여부를 확인하세요. 트래픽이 잘못 분기되면 먼저 규칙이 도메인과 조회 후 IP 중 무엇을 대상으로 하는지 확인한 다음 도메인 규칙을 추가하거나 데이터를 업데이트하세요.; GEOIP / GEOSITE

rule-providers: rule-providers는 규칙을 별도의 모음으로 관리하고 RULE-SET 규칙에서 이를 참조합니다. 모음의 behavior와 format은 파일 내용과 일치해야 합니다. 예를 들어 도메인 목록과 전체 규칙 목록은 작성 방식이 다릅니다. 실제로 적용할 정책은 참조하는 규칙에서 지정합니다. proxy-providers와 달리 rule-providers는 일치 조건을 제공하며 연결에 사용할 프록시 노드를 제공하지 않습니다.; rule-providers / RULE-SET / behavior

Rule, Global, Direct 모드: Rule 모드는 설정된 규칙에 따라 트래픽을 분기합니다. Global 모드는 코어에 들어온 연결을 전역 정책으로 보내며, Direct 모드는 대상에 직접 연결합니다. 모드는 코어에 들어온 트래픽에만 영향을 줍니다. Global로 바꿔도 프록시가 설정되지 않은 앱의 트래픽을 자동으로 가져오지 않으며, TUN을 활성화하는 것과도 다릅니다. 문제를 해결할 때 모드를 전환해 원인을 좁히고 규칙 선택과 노드 연결 중 어느 단계에 문제가 있는지 확인한 뒤 평소 설정으로 되돌리세요.; mode: rule / global / direct

LINUX / RUNTIME

Linux 시스템 구성 요소

권한, 프로세스, 라우팅은 시스템 계층에 속합니다. 설정 문법이 올바르다고 해서 실행에 필요한 조건까지 충족되는 것은 아닙니다.

TUN 모드: TUN은 가상 네트워크 장치로 IP 패킷을 받아 라우팅 및 DNS 설정과 함께 애플리케이션 트래픽을 처리합니다. Linux에서는 보통 적절한 네트워크 관리 권한이 필요합니다. tun.enable을 활성화한 뒤에도 장치와 라우팅 상태, 다른 VPN과의 충돌을 확인해야 합니다. 인터페이스의 스위치만 확인해서는 안 됩니다. tun.stack은 프로토콜 스택 구현을 결정하며, 트래픽 분기 방식인 rule이나 global 모드와는 별개의 설정입니다.; tun.enable / tun.stack / tun.auto-route

systemd 사용자 서비스: systemd 사용자 서비스는 사용자 단위 관리자가 실행하며 systemctl --user로 관리합니다. 서비스 파일은 보통 ~/.config/systemd/user/에 둡니다. 시스템 서비스와 관리 범위, 권한, 로그 컨텍스트가 다릅니다. 사용자가 로그아웃한 뒤에도 실행을 유지할 수 있는지는 사용자 관리자의 수명 주기와 linger 설정에 따라 달라집니다. 서비스 파일을 수정한 뒤에는 daemon-reload를 실행하고 서비스를 다시 시작하세요.; systemctl --user status mihomo

Linux capabilities: Linux capabilities는 일부 특권을 프로세스에 개별적으로 부여할 수 있는 권한으로 나눕니다. 예를 들어 CAP_NET_ADMIN은 네트워크 장치와 라우팅 관리에 관련됩니다. 바이너리에 capability를 설정하기 전에 파일 출처와 실제 필요성을 확인하세요. 실행 파일을 교체하면 기존 파일 capability가 무효화될 수 있으므로 다시 확인해야 합니다. 파일 capability, systemd의 capability 제한, 실행 환경이 함께 결과에 영향을 줍니다. 권한 오류가 발생하면 서비스 로그도 확인하세요.; CAP_NET_ADMIN / getcap / setcap

프록시 환경 변수: http_proxy, https_proxy, all_proxy는 이를 지원하는 애플리케이션에 프록시 주소를 전달하고, no_proxy는 프록시를 우회할 대상을 지정합니다. 변수는 보통 프로세스를 시작할 때 환경에서 상속되므로 이미 실행 중인 프로그램에는 자동으로 적용되지 않습니다. 도구마다 대소문자나 프로토콜 형식 지원이 다를 수 있습니다. 데스크톱 브라우저, 터미널 명령, systemd 서비스의 환경은 서로 다를 수 있으므로 터미널에서 테스트에 성공했다고 모든 앱이 프록시를 사용한다고 단정할 수 없습니다.; http_proxy / https_proxy / all_proxy / no_proxy