Clash 자주 묻는 질문

Clash는 보통 프록시 코어와 그 설정 생태계를 가리킵니다. mihomo는 Clash Meta의 계보를 잇는 코어로, 프로토콜 연결과 규칙 매칭, 트래픽 전달을 담당합니다. Mac용 GUI 클라이언트는 코어에 메뉴 막대, 구독 관리, 시스템 프록시 전환 기능을 더합니다. 두 클라이언트가 모두 mihomo를 사용하더라도 설정 메뉴와 보조 서비스, 코어 업데이트 주기는 다를 수 있습니다. 문제를 진단할 때는 Clash라고만 적지 말고 클라이언트 이름과 버전, 코어 버전을 함께 기록하세요. 기존 설정을 그대로 쓸 수 있는지는 세부 필드에 따라 달라집니다. 화면이 비슷하다고 지원 범위까지 같은 것은 아닙니다.

클라이언트는 설정을 실행하는 도구일 뿐, 설치만으로 사용할 수 있는 원격 프록시가 자동으로 생기지는 않습니다. 구독은 보통 서비스 제공자가 제공하며 노드, 프록시 그룹, 규칙을 가져오는 데 사용합니다. 직접 관리하는 로컬 설정 파일을 가져올 수도 있습니다. 가져오기 전에 제공된 형식이 Clash 또는 mihomo와 호환되는지, 유효 기간과 기기 제한은 어떤지 확인하세요. 구독 주소에는 계정 인증 정보가 포함될 수 있으므로 비밀번호처럼 관리하고 공개 게시판이나 스크린샷, 온라인 변환 사이트에 올리지 마세요. 아직 설정이 없다면 우선 설치만 마치면 됩니다. 시스템 프록시를 반복해서 켜도 연결 정보가 생기지는 않습니다.

일상적인 사용에는 보통 규칙 모드를 선택합니다. 설정에 정의된 규칙에 따라 트래픽이 사용할 아웃바운드가 결정됩니다. 전역 모드는 연결을 전역 프록시 그룹에 전달하지만, 그룹에서 사용 가능한 아웃바운드를 선택해야 합니다. 또한 모든 프로그램의 트래픽이 클라이언트로 전달되는 것은 아닙니다. 직접 연결 모드는 이미 클라이언트가 가로챈 연결을 대상에 바로 연결하는 방식이며, 시스템 프록시를 끄거나 클라이언트를 종료하는 것과는 다릅니다. 특정 사이트에 문제가 생기면 모드를 잠시 바꿔 비교한 뒤 규칙 모드로 돌아와 적용된 규칙을 확인하세요. 앱의 트래픽을 가로채는 방법과 아웃바운드를 선택하는 방법은 별개입니다. 전자는 시스템 프록시, 앱 설정, TUN 같은 진입 경로에 따라 달라집니다.

일반적인 HTTPS 연결은 앱과 대상 웹사이트 사이에서 암호화되므로, 보통 프록시를 중계하는 데 루트 인증서가 필요하지 않습니다. 다만 프록시 서비스 제공자는 연결 시간, 대상 주소, 트래픽 규모 같은 메타데이터를 확인할 수 있으므로 데이터 처리 방침을 살펴보세요. 인증서를 설치하고 HTTPS 복호화를 켜야 하는 작업이라면 목적과 신뢰 범위를 별도로 검토해야 합니다. 클라이언트 로그에도 도메인, 연결 오류, 설정 파일 경로가 남을 수 있습니다. 진단 정보를 공유하기 전에는 구독 주소와 인증 정보, 개인 정보를 가리세요. 프록시를 켰다고 모든 접속을 추적할 수 없게 되는 것은 아닙니다.

Apple 메뉴에서 ‘이 Mac에 관하여’를 열어 확인하세요. Apple M 시리즈 칩이 표시되면 arm64 또는 Apple Silicon 설치 파일을, Intel 프로세서가 표시되면 x64 또는 x86_64 설치 파일을 선택합니다. Universal 범용 설치 파일이 제공된다면 해당 클라이언트의 안내에 따라 설치할 수 있습니다. Apple Silicon에서 Intel 버전을 실행하려면 Rosetta가 필요할 수 있지만, 호환성 문제를 줄이려면 네이티브 아키텍처 버전을 우선 선택하세요. 클라이언트가 요구하는 최소 macOS 버전도 확인해야 합니다. 아키텍처가 맞아도 macOS 버전이 낮으면 실행할 수 없습니다. 설치 파일 페이지에서 자세한 안내를 확인하고, MacBook의 외관이나 구매 연도만으로 판단하지 마세요.

먼저 시스템 경고의 내용을 확인하고 설치 파일의 출처, 칩 아키텍처, 시스템 요구 사항을 점검하세요. 앱을 응용 프로그램 폴더로 옮긴 뒤 다시 열어 보세요. 시스템이 실행을 차단하면 시스템 설정의 ‘개인정보 보호 및 보안’에서 ‘그래도 열기’ 옵션이 있는지 확인하고, 출처를 확인한 앱에만 사용하세요. 손상 경고는 다운로드가 불완전하거나 서명에 문제가 있거나 버전이 호환되지 않을 때도 나타날 수 있습니다. 설치 파일을 다시 받고 릴리스 노트를 확인하세요. 알 수 없는 앱을 실행하려고 시스템 보안을 전역으로 끄거나, 출처가 불분명한 터미널 명령을 그대로 복사하지 마세요. 악성 소프트웨어 경고가 뜨면 실행을 중단하고 출처를 확인하세요.

클라이언트의 구독 또는 설정 화면에서 URL 가져오기를 선택한 다음 서비스 제공자가 준 전체 주소를 붙여넣고 저장하세요. 가져오기와 파싱이 끝날 때까지 기다립니다. 이후 해당 설정을 현재 설정으로 선택하고, 프록시 화면에 관련 프록시 그룹이 표시되는지 확인하세요. 수동 선택이 필요한 그룹에서는 아웃바운드도 지정해야 합니다. 구독 목록에 항목이 보인다는 것은 주소가 저장됐다는 뜻일 뿐, 다운로드에 성공했거나 설정이 활성화됐다는 뜻은 아닙니다. 가져오기에 실패하면 HTTP 상태 코드와 파싱 오류를 확인해 주소에 접근할 수 없는 문제인지, 형식이 호환되지 않는 문제인지 구분하세요. 웹사이트 계정 로그인 주소를 구독 주소로 사용하지 마세요. 로컬 파일은 파일 가져오기 메뉴에서 열어야 합니다.

TUN은 가상 네트워크 인터페이스를 만들고 라우팅을 변경해야 합니다. Mac 클라이언트는 보통 특권 보조 서비스를 통해 이 작업을 수행하므로 관리자 권한을 요청할 수 있습니다. 먼저 클라이언트 설정의 안내에 따라 보조 서비스를 설치하거나 복구한 뒤 TUN을 켜고, 코어 로그에서 인터페이스 생성이 성공했는지 확인하세요. 권한 요청을 취소했거나 서비스가 실행되지 않았거나 서비스와 클라이언트 버전이 맞지 않으면 스위치가 바로 꺼질 수 있습니다. 다른 VPN이나 터널링 도구를 잠시 종료하고 다시 시도할 수 있지만, 시스템 네트워크 설정을 함부로 삭제하지 마세요. 조직에서 관리하는 기기라 권한이 없다면 관리자에게 문의하세요. 시스템 프록시를 지원하는 앱이라면 임시 대안으로 사용할 수 있습니다.

먼저 코어가 실행 중이고 현재 설정이 유효한지 확인하세요. 시스템 프록시의 주소와 포트가 클라이언트의 실제 수신 주소 및 포트와 일치해야 합니다. 그런 다음 시스템 설정의 네트워크에서 현재 사용 중인 Wi-Fi 또는 이더넷 서비스의 프록시 설정을 확인하세요. 네트워크 서비스를 바꾸면 이전 서비스의 설정이 적용되지 않을 수 있습니다. 브라우저 확장 프로그램이나 앱 내 프록시, 다른 VPN이 연결 경로를 바꿀 수도 있습니다. 클라이언트의 연결 화면을 열고 테스트 사이트를 새로고침해 연결 항목과 아웃바운드가 표시되는지 확인하세요. 연결이 없다면 트래픽을 가로채는 진입 경로부터 점검하세요. 연결은 있지만 직접 연결로 표시된다면 시스템 프록시 스위치를 반복해서 누르기보다 규칙과 우회 목록을 확인하세요.

많은 명령줄 프로그램은 macOS 시스템 프록시를 읽지 않고 자체 설정이나 프록시 환경 변수를 사용합니다. 먼저 클라이언트에서 실제 HTTP 또는 혼합 포트가 무엇인지 확인한 다음 각 도구의 문서에 따라 프록시를 설정하세요. 예를 들어 curl은 명령에 프록시 옵션을 지정할 수 있고, Git은 자체 프록시 설정을 사용할 수 있습니다. 시스템 프록시를 따르지 않는 프로그램까지 더 폭넓게 처리해야 한다면 TUN 사용을 검토하세요. 문제를 진단할 때 예전 HTTP_PROXY, HTTPS_PROXY, ALL_PROXY 환경 변수가 종료된 클라이언트나 이전 포트를 가리키고 있지 않은지 확인하세요. 변수를 바꾼 뒤에는 현재 터미널 세션에 변경 사항이 반영됐는지도 점검해야 합니다. 여러 진입 경로를 한꺼번에 바꾸면 원인을 파악하기 어렵습니다.

먼저 연결 화면에서 해당 요청을 찾아 실제 도메인과 적용된 규칙, 최종 아웃바운드를 확인하세요. 규칙은 보통 순서대로 매칭되므로 앞쪽의 넓은 규칙이 뒤쪽의 구체적인 규칙보다 먼저 적용될 수 있습니다. 프록시 그룹이 다른 그룹을 참조할 수도 있으니 그룹 간 연결을 따라가며 최종 선택을 확인하세요. 특정 도메인의 경로를 바꾸려면 클라이언트가 지원하는 오버라이드나 추가 규칙 기능을 우선 사용하고, 규칙 삽입 순서 안내를 따르세요. 구독으로 내려받은 파일을 직접 수정하면 다음 업데이트 때 변경 사항이 사라질 수 있습니다. 규칙에서 지정한 프록시 그룹 이름이 실제로 존재하는지도 확인하세요. 수정 후 설정을 다시 불러오고 새 연결을 만들어야 합니다. 기존 연결은 바로 경로가 바뀌지 않을 수 있습니다.

이 문제는 Windows 앱 컨테이너와 관련된 것으로, macOS 권한 설정과는 무관합니다. 앱 컨테이너에서 실행되는 일부 UWP 앱은 기본적으로 로컬 루프백 주소에 접근할 수 없습니다. 데스크톱 프록시는 보통 로컬 주소에서 수신 대기하므로 브라우저가 정상이라고 해서 해당 앱도 연결된다는 뜻은 아닙니다. 먼저 Windows 클라이언트에서 제공하는 루프백 예외 도구를 사용해 필요한 앱이 로컬 프록시에 접근하도록 허용하고, 관리자 권한 요청 안내를 따르세요. 클라이언트가 지원한다면 TUN으로 트래픽을 가로채는 방법도 검토할 수 있지만, 앱 자체 동작과 다른 방화벽 제한도 확인해야 합니다. Mac에서 같은 이름의 스위치를 찾거나 방화벽 전체를 계속 꺼 두는 방식으로 우회하지 마세요.

먼저 서비스 제공자 계정에서 이용 기간과 트래픽 상태를 확인하고 구독 주소가 재설정됐는지 살펴보세요. 401은 대개 인증 문제, 403은 접근 정책이나 계정 제한, 404는 링크 변경과 관련될 수 있지만 정확한 원인은 서비스 제공자의 안내를 따르세요. 로그인 페이지나 인증 화면이 반환되면 설정 파일이 아닌 콘텐츠를 받았기 때문에 클라이언트가 파싱에 실패할 수 있습니다. 주소 전체가 맞는지 확인한 뒤 다시 업데이트하고, 클라이언트에서 지원한다면 직접 연결 또는 프록시 경유로 가져오기를 시도하세요. 구독을 가져오는 경로가 이미 끊긴 연결에 의존하지 않도록 하는 것이 좋습니다. 기존에 작동하는 설정은 보존하고 구독을 전부 지우지 마세요. 서비스 제공자에게 문의할 때는 상태 코드와 발생 시각을 전달하되 전체 링크는 공개하지 마세요.

먼저 프록시를 끄고 기본 네트워크가 정상인지 확인한 다음, 특정 아웃바운드 문제인지 모든 아웃바운드의 문제인지 구분하세요. 하나만 시간 초과된다면 같은 프록시 그룹의 다른 아웃바운드로 바꾸고 해당 서비스의 점검 여부를 확인하세요. 모두 시간 초과된다면 구독 상태와 시스템 시간, 설정에 사용된 프로토콜의 코어 지원 여부, 로그에 나타난 파싱·핸드셰이크·인증 오류를 점검하세요. 연결 테스트의 시간 초과는 테스트 주소가 작동하지 않거나 제한 시간이 너무 짧아서 발생할 수도 있습니다. 테스트 결과만으로 노드가 끊겼다고 단정하지 말고 실제 웹 요청도 확인하세요. 네트워크를 바꾼 뒤 정상화된다면 현재 네트워크 경로가 원인일 가능성이 있습니다. 진단 중에는 한 번에 한 가지 조건만 바꾸고 결과를 기록하세요.

먼저 로그에서 도메인 해석 실패, DNS 요청 시간 초과, 라우팅 루프가 나타나는지 확인하세요. 그런 다음 현재 설정의 DNS 서버와 TUN DNS 하이재킹, 라우팅 설정이 서로 맞물리는지 살펴보세요. 브라우저의 보안 DNS나 다른 VPN, 시스템에서 직접 지정한 DNS 때문에 앱마다 다른 경로로 도메인을 해석할 수 있습니다. macOS의 DNS 진단 도구와 앱이 같은 경로를 사용한다고 보장할 수 없으므로 한 번의 명령 결과가 모든 앱의 상태를 나타내지는 않습니다. fake-ip를 사용한다면 관련 주소가 올바르게 가로채지는지 확인하고, 호환되지 않는 LAN 서비스는 설정 안내에 따라 예외로 지정하세요. 먼저 정상 작동이 확인된 설정으로 비교하고 DNS, 규칙, 모든 노드를 한꺼번에 바꾸지 마세요.

클라이언트를 열 수 있다면 먼저 시스템 프록시와 TUN을 끈 뒤 정상 종료하고 네트워크가 복구되는지 확인하세요. 앱이 이미 비정상 종료됐다면 시스템 설정의 네트워크에서 현재 사용 중인 서비스를 선택하고, 세부 정보의 프록시 화면에 로컬 주소를 가리키는 설정이 남아 있는지 확인하세요. 해당 클라이언트가 설정한 항목임을 확인한 뒤 끄고 설정을 적용합니다. 다른 VPN과 터미널의 프록시 환경 변수, 직접 지정한 DNS도 함께 확인하세요. 관리 기기의 프록시는 조직에서 설정했을 수 있으므로 바로 삭제하지 마세요. TUN 경로나 보조 서비스가 정상적으로 정리되지 않았다면 작업을 저장한 뒤 Mac을 재시동하고, 프록시를 거치지 않는 요청으로 기본 네트워크를 확인하세요.