Clash 자주 묻는 질문
설정 및 연결 문제 해결

클라이언트는 구독 관리, 프록시 그룹 선택, 시스템 프록시 설정을 담당하고, mihomo 커널은 포트 수신, DNS 조회, 트래픽 분기 규칙 실행을 담당합니다. Linux 데스크톱에서는 Clash Verge Rev를 사용할 수 있고, 서버에서는 커널을 직접 실행할 수 있습니다. 두 프로그램의 설정 저장 위치는 다를 수 있으며, GUI 클라이언트가 실행용 설정 파일을 별도로 생성하기도 합니다. 문제를 해결하기 전에 실제로 실행 중인 바이너리와 설정 디렉터리를 확인하고, 사용하지 않는 다른 config.yaml을 수정하지 마세요. 명령줄로 설치한 경우 보통 ~/.config/mihomo/를 사용하지만, 최종 기준은 실행 인수의 -d 또는 -f입니다.

평소에는 규칙 모드인 mode: rule을 선택한 뒤 요청에 적용된 규칙과 프록시 그룹을 확인하세요. 전역 모드는 일반 연결을 GLOBAL 프록시 그룹으로 보내지만, 해당 그룹에서 DIRECT를 선택할 수도 있습니다. 또한 커널을 거치지 않는 프로그램의 트래픽까지 자동으로 처리하지는 않습니다. 직접 연결 모드는 커널에 들어온 연결을 대상에 바로 연결하므로 비교 테스트에 적합합니다. 모드를 바꾼 뒤에는 새 연결을 만들어야 합니다. 기존 장기 연결은 이전 경로를 계속 사용할 수 있습니다. 특정 프로그램에서 변화가 없다면 모드 설정을 확인하기 전에 시스템 프록시를 사용 중인지, TUN이 트래픽을 처리하는지부터 확인하세요.

클라이언트와 커널은 연결 및 트래픽 분기 기능을 제공하지만, 설치만으로 사용할 수 있는 원격 프록시가 준비되는 것은 아닙니다. 구독에는 보통 노드, 프록시 그룹 또는 규칙이 포함되며 노드 목록만 제공하는 경우도 있습니다. 가져오기 전에 서비스 제공자가 Clash 또는 mihomo에서 인식할 수 있는 형식을 제공하는지 확인하세요. 노드만 포함된 Provider 파일은 전체 설정을 대신할 수 없습니다. 가져온 뒤에는 해당 설정을 활성화하고, 프록시 그룹에서 사용 가능한 출구 노드를 선택한 다음 서비스 유효 기간과 데이터 한도를 확인해야 합니다. 구독 링크에는 접근 인증 정보가 포함될 수 있으므로 공개 로그나 스크린샷, 온라인 변환 사이트에 올리지 마세요.

둘 다 켤 필요는 없습니다. 시스템 프록시는 데스크톱 프록시 설정을 따르는 브라우저와 앱에 적합하고, TUN은 가상 네트워크 장치와 라우팅을 통해 더 많은 연결을 처리합니다. 처음 설치할 때는 TUN을 끄고 명시적 프록시로 노드와 포트를 확인한 다음 TUN을 따로 테스트하면 설정 문제와 시스템 권한 문제를 구분하기 쉽습니다. 둘을 함께 사용한다면 중복으로 트래픽을 처리하거나 연결 루프가 발생하지 않도록 클라이언트의 라우팅 제외 설정과 DNS 설정도 확인하세요. TUN을 켠다고 모든 트래픽이 반드시 프록시를 거치는 것은 아닙니다. 최종 연결 경로는 규칙, 프록시 그룹, 우회 설정에 따라 달라집니다.

가져온 설정이 설정 목록에 저장만 된 것이 아니라 현재 사용 중인 설정으로 지정되어 있는지 먼저 확인하세요. 그런 다음 구독 업데이트 로그에서 응답이 실제로 로그인 페이지나 오류 페이지 또는 빈 파일인지 확인합니다. 설정에 proxy-providers가 있다면 기본 설정이 정상적으로 로드되어도 노드 목록을 가져오지 못했을 수 있습니다. 해당 Provider의 상태와 경로, 원격 서버 응답도 확인하세요. 명령줄 환경에서는 mihomo -t -d ~/.config/mihomo로 설정을 검사한 다음 실행 로그에서 다운로드 오류를 확인할 수 있습니다. 인증 정보가 포함된 구독 URL을 공개 질문 게시판에 올리지 마세요.

401은 보통 인증 정보가 없거나 만료된 경우 발생하므로 서비스 제공자에게 새 링크를 요청하세요. 403은 접근 정책, 요청 헤더, 이용 한도와 관련될 수도 있으니 응답 본문을 함께 확인해야 합니다. 시간 초과가 발생하면 먼저 네트워크에서 구독 주소에 접속할 수 있는지 확인하세요. 구독을 가져올 때 사용하는 프록시가 아직 로드되지 않은 노드에 의존하는지도 살펴보세요. 인증서 오류가 발생하면 timedatectl로 시스템 시간을 확인하고 배포판의 CA 인증서도 점검하세요. 인증서 검증을 끄는 방식으로 오류를 계속 우회하지 마세요. 링크가 갱신되었다면 이전 주소를 새 주소로 바꾸고 직접 새로고침한 뒤 HTTP 상태 코드와 로그를 확인하세요.

먼저 ls -l /dev/net/tun을 실행해 장치가 있는지 확인하세요. 장치가 없으면 tun 모듈을 확인하고 필요한 경우 sudo modprobe tun을 실행합니다. 다음으로 실행 중인 커널이 가상 네트워크 인터페이스를 만들고 라우팅을 수정할 권한을 갖고 있는지 확인하세요. 가능하면 GUI 클라이언트에서 제공하는 서비스 설치 방법을 이용하는 것이 좋습니다. 직접 설치한 경우 일부 환경에서는 sudo setcap cap_net_admin,cap_net_bind_service=+ep /usr/local/bin/mihomo로 권한을 부여할 수 있지만, 실제 바이너리 경로와 일치해야 합니다. 바이너리를 업데이트한 뒤에는 권한을 다시 설정해야 할 수 있습니다. 컨테이너에서는 장치와 네트워크 기능을 허용해야 하며, systemd의 기능 제한으로 권한 부여가 적용되지 않을 수도 있습니다.

먼저 systemctl --user cat mihomo를 실행해 ExecStart를 확인하고 바이너리와 설정 디렉터리가 모두 존재하는지 살펴보세요. 서비스에는 명확한 경로를 지정하는 것이 좋습니다. 설정 디렉터리로 %h/.config/mihomo를 사용할 수 있으며, 셸이 ~를 확장하거나 대화형 터미널의 환경 변수를 읽을 것이라고 가정하지 마세요. 그런 다음 mihomo -t -d ~/.config/mihomo로 같은 디렉터리의 설정을 검사하고, journalctl --user -u mihomo -b -n 80 --no-pager로 종료 원인을 확인하세요. 서비스 파일을 수정한 뒤 systemctl --user daemon-reload를 실행하고 서비스를 다시 시작합니다. 사용자 서비스 명령과 시스템 서비스 명령을 혼용하지 마세요.

데스크톱 시스템 프록시는 모든 트래픽을 처리하는 공통 인터페이스가 아닙니다. 일부 명령줄 프로그램은 환경 변수만 읽고, 일부 앱은 자체 프록시 설정을 사용합니다. 먼저 curl -I -x http://127.0.0.1:7890 https://example.com으로 명시적 프록시 연결을 확인한 뒤 프로그램 설명서에 따라 http_proxy, https_proxy 또는 ALL_PROXY를 설정하세요. 환경 변수 이름의 대소문자 지원은 프로그램마다 다를 수 있으며, NO_PROXY에 따라 대상이 프록시를 우회할 수도 있습니다. 프록시 설정을 지원하지 않는 프로그램까지 처리해야 한다면 명시적 프록시 연결을 확인한 뒤 TUN 사용을 고려하세요. 데스크톱 프록시 스위치만 보고 터미널 트래픽도 프록시를 거친다고 판단하지 마세요.

먼저 일반 데스크톱 브라우저가 같은 포트로 연결되는지 확인한 뒤 앱 컨테이너의 루프백 제한 여부를 살펴보세요. 일부 UWP 앱은 127.0.0.1의 프록시에 연결하려면 루프백 예외가 필요합니다. 클라이언트에서 제공하는 UWP 루프백 설정을 우선 사용하고 필요한 앱만 선택하세요. 관리자 터미널에서 CheckNetIsolation LoopbackExempt -s를 실행하면 현재 예외 목록을 확인할 수 있습니다. 직접 수정하려면 패키지 패밀리 이름이 정확한지 먼저 확인하세요. 필요한 앱에만 허용하고, 알 수 없는 앱을 일괄 수정하지 마세요. TUN을 이미 켰다면 해당 앱의 트래픽이 실제로 커널에 전달되는지도 확인해야 합니다. 모든 문제를 루프백 제한 탓으로 돌리지 마세요.

수신 주소, allow-lan, 방화벽 설정이 모두 올바르게 구성되어야 합니다. allow-lan: true를 켠 뒤 bind-address가 LAN 주소를 허용하는지 확인하고 ss -lntp로 실제 수신 주소를 확인하세요. 다른 기기에서는 127.0.0.1이 아니라 이 컴퓨터의 LAN IP와 mixed-port를 입력해야 합니다. 방화벽에서는 신뢰할 수 있는 네트워크에만 프록시 포트를 열고 필요에 따라 프록시 인증을 설정하세요. external-controller 관리 인터페이스는 접근 제어를 명확히 설정한 경우가 아니라면 로컬에서만 접근할 수 있도록 제한해야 합니다. HTTP 프록시 공유와 컴퓨터를 투명 게이트웨이로 사용하는 것은 서로 다른 구성입니다. 프록시 포트만 설정했다고 게이트웨이 구성이 완료되는 것은 아닙니다.

HTTP 유형의 proxy-providers는 interval로 업데이트 간격을 지정할 수 있으며 단위는 초입니다. 예를 들어 interval: 3600은 한 시간마다 확인한다는 뜻입니다. Provider마다 별도의 캐시 경로를 사용하고 실행 중인 사용자에게 해당 디렉터리의 쓰기 권한이 있는지 확인하세요. health-check.interval은 노드 상태 확인 간격이며 구독 업데이트 주기가 아닙니다. 값을 줄여도 새 노드를 더 빨리 가져오지 못하고 요청과 전력 소비만 늘어날 수 있습니다. GUI 클라이언트의 설정 업데이트 일정은 커널 Provider의 동작과 별도로 관리될 수도 있습니다. 전체 설정을 업데이트할지 노드 목록만 업데이트할지 먼저 확인하세요. 설정을 수정하기 전에 백업하고 로그에서 실제 가져오기 결과를 확인하세요.

먼저 구독이 유효한지, 프록시 그룹에서 원격 노드를 실제로 선택했는지 확인한 다음 노드 서버 주소가 조회되는지와 시스템 시간이 정확한지 점검하세요. 특정 노드만 실패하고 다른 노드는 작동한다면 해당 노드나 테스트 대상부터 확인하세요. 모든 노드가 실패한다면 로컬 네트워크, 방화벽, 구독 상태, 커널 로그를 살펴보세요. 지연 시간 테스트 결과는 지정된 테스트 주소와의 연결만 보여 줄 뿐 모든 웹사이트에 접속할 수 없다는 뜻은 아닙니다. 명시적 프록시로 실제 이용하려는 HTTPS 사이트에 요청해 비교하고 연결 단계에서 발생한 오류를 기록하세요. DNS, 포트, 모드를 한꺼번에 바꾸지 말고 한 번에 하나씩만 수정해야 어떤 문제가 해결됐는지 알 수 있습니다.

먼저 mixed-port가 수신 중인지 확인한 다음 명시적 HTTP 프록시와 브라우저 연결 결과를 비교하세요. curl -I -x http://127.0.0.1:7890 https://example.com을 실행해 볼 수 있습니다. 요청은 성공하지만 브라우저에서 실패한다면 브라우저 프록시 설정, 확장 프로그램, 보안 DNS를 확인하세요. 로그에 도메인 조회 오류가 표시되면 dns.enable, 업스트림 DNS 연결 상태, TUN의 DNS 처리 설정을 확인합니다. fake-ip 모드에서 매핑 주소가 반환되는 것은 일반적으로 정상 동작이므로 주소만 보고 오류라고 판단하면 안 됩니다. 앱이 이전 DNS 결과를 캐시했다면 앱을 다시 시작해 새 연결을 만들고, 필요하면 시스템과 브라우저의 캐시를 각각 확인하세요.

ss -lntp를 실행해 TCP 수신 포트를 확인하고 특히 mixed-port와 external-controller에 지정된 포트를 살펴보세요. 다른 사용자의 프로세스를 확인해야 한다면 sudo를 사용합니다. GUI 클라이언트와 직접 실행한 커널을 동시에 사용하거나 사용자 서비스와 시스템 서비스가 중복으로 실행되는 경우가 흔한 원인입니다. 먼저 어떤 프로세스가 포트를 사용 중인지 확인한 뒤 필요 없는 인스턴스만 중지하세요. 이름이 같은 프로세스를 모두 종료하지 마세요. 충돌한 포트를 변경할 수도 있지만 시스템 프록시, 환경 변수, 패널 연결 주소도 함께 수정해야 합니다. UDP 수신 오류라면 ss -lnup도 확인해 TCP만 살펴보고 포트가 비어 있다고 잘못 판단하지 않도록 하세요.

먼저 systemctl --user is-enabled mihomo와 systemctl --user status mihomo를 실행해 서비스가 활성화되지 않은 것인지, 시작에 실패한 것인지 구분하세요. 사용자 관리자가 부팅 후 서비스를 시작하도록 하려면 systemctl --user enable --now mihomo를 실행할 수 있습니다. 로그아웃 후에도 사용자 서비스가 계속 실행되는지는 linger 설정에 따라 달라집니다. loginctl show-user "$USER" -p Linger로 확인하세요. 로그인하지 않은 상태에서도 실행이 필요하다면 loginctl enable-linger의 영향을 검토한 뒤 설정하세요. TUN에 추가 권한이 필요하다면 업데이트 후 권한이 사라지지 않았는지도 별도로 확인합니다. 마지막으로 서비스 상태만 확인하지 말고 데스크톱 프록시나 터미널 변수가 실제 수신 중인 포트를 가리키는지도 점검하세요.