1단계: 구독 또는 로컬 YAML 가져오기
클라이언트를 열고 사이드바에서 ‘설정’ 또는 ‘구독’ 페이지로 이동한 뒤 ‘새로 만들기’, ‘추가’ 또는 ‘가져오기’ 항목을 찾습니다. 원격 구독을 사용할 경우 URL 가져오기를 선택하고 서비스 제공자가 안내한 전체 링크를 주소 입력란에 붙여 넣은 다음 다운로드 또는 저장을 누릅니다. ‘일상용 설정’처럼 용도를 알아보기 쉬운 이름을 지정해도 됩니다. 이름은 항목을 구분하기 위한 것으로 노드나 규칙에는 영향을 주지 않습니다. 링크에 접근 매개변수가 포함되어 있다면 그대로 유지하고, 브라우저에 표시된 페이지 제목이나 설명은 복사하지 마세요.
다운로드가 끝나면 해당 항목에 성공 상태가 표시되는지 확인한 뒤 ‘사용’, ‘활성화’ 또는 이에 해당하는 선택 버튼을 누릅니다. 가져온 설정을 자동으로 활성화하는 클라이언트도 있고, 파일만 목록에 추가하는 클라이언트도 있습니다. 항목이 목록에 보이는지만으로 판단하지 말고 ‘프록시’ 페이지에 해당 설정의 정책 그룹과 노드가 표시되는지 확인하세요. 프록시 페이지로 이동해 내용이 불러와졌는지 살펴본 다음 다음 단계로 진행합니다.
파일을 받은 경우 같은 페이지에서 ‘로컬 파일 가져오기’를 선택하고 확장자가 .yaml 또는 .yml인 설정 파일을 지정합니다. 파일을 이미지, 웹페이지 또는 서식 있는 텍스트 형식으로 바꾸지 말고, 확장자만 바꿔 다른 구독 형식을 YAML로 취급하지도 마세요. 클라이언트에 설정 검사 기능이 있다면 먼저 실행하세요. 오류 메시지에 표시된 필드 이름과 줄 번호가 단순한 ‘가져오기 실패’ 메시지보다 원인을 찾는 데 도움이 됩니다.
가져오기에 실패했을 때 확인할 순서
먼저 현재 네트워크에서 링크를 다운로드할 수 있는지, 응답 내용이 호환되는 설정인지 확인하세요. 로그인 페이지, 만료 안내, 웹 오류 페이지가 반환되는 경우도 있습니다. 다음으로 서비스 제공자가 Clash용 구독과 다른 형식의 구독 URL을 구분하는지 확인합니다. 구독 주소에 일시적으로 접속할 수 없다면 제공자에게 로컬 설정 파일을 받아 가져오면 됩니다. 시스템 프록시를 먼저 반복해서 변경할 필요는 없습니다. YAML 들여쓰기와 일반 필드 문제는 설정 필드 안내에서 하나씩 확인하세요.
구독을 업데이트하면 원격 내용을 다시 가져옵니다. 첫 연결 단계에서는 가져온 결과를 그대로 두고 원본 파일을 서둘러 수정하지 마세요. 이후 사용자 지정 규칙을 계속 유지해야 한다면 클라이언트가 지원하는 덮어쓰기 기능을 사용하세요. 자세한 내용은 덮어쓰기 및 병합을 참고하세요. 이렇게 하면 다음 업데이트 때 로컬 변경 사항이 덮어써지는 일을 줄일 수 있습니다.
2단계: 규칙 모드와 출구 선택
설정이 활성화되었는지 확인한 뒤 클라이언트의 ‘프록시’ 페이지로 이동하거나 메뉴 막대 아이콘에서 모드 메뉴를 엽니다. 처음에는 ‘규칙’ 모드를 선택하는 것이 좋습니다. Rule로 표시될 수도 있습니다. 이 모드에서는 코어가 설정의 규칙에 따라 요청을 직접 연결하거나 거부하거나 정책 그룹으로 전달합니다. 모든 트래픽을 하나의 노드로 보내는 스위치가 아니므로 웹사이트마다 출구가 다른 것은 정상입니다.
그다음 주요 정책 그룹을 펼쳐 현재 선택된 항목을 확인합니다. 그룹 이름은 설정 작성자가 정하므로 ‘프록시 선택’, ‘자동 선택’ 또는 다른 이름일 수 있습니다. 이름만 보고 용도를 추측하지 마세요. 규칙에서 실제로 참조하는 선택 그룹을 찾아 기존 노드를 지정하거나 설정에 포함된 자동 선택 그룹을 사용합니다. 그룹에서 DIRECT가 선택되어 있으면 해당 요청은 직접 연결됩니다. 관련 규칙이 연결을 프록시로 전달하려면 원격 노드나 노드를 포함한 유효한 그룹을 선택해야 합니다.
노드 테스트는 연결 가능성을 대략 확인하는 데 유용하지만, 테스트에 성공해도 모든 웹사이트에 접속할 수 있는 것은 아니며 실패해도 테스트 주소와 현재 네트워크를 함께 살펴봐야 합니다. 처음에는 사용 가능한 노드를 하나 직접 선택한 뒤 선택을 유지한 채 연결을 확인하세요. DNS 변경, 규칙 순서 수정, 정책 그룹 유형 변경을 동시에 하지 마세요. 문제가 생겼을 때 원인을 찾기 어려워집니다.
| 모드 | 요청 처리 방식 | 첫 설정에서의 용도 |
|---|---|---|
| 규칙 / Rule | 규칙 일치 결과에 따라 출구를 선택합니다. | 일상적인 사용 및 기본 연결 확인 |
| 전역 / Global | 코어로 들어온 요청을 전역 정책에 따라 처리합니다. | 규칙이 결과에 영향을 주는지 일시적으로 비교할 때 |
| 직접 연결 / Direct | 코어로 들어온 요청을 보통 대상에 직접 연결합니다. | 로컬 네트워크 접속 상태와 비교할 때 |
여기서 ‘전역’은 코어에 들어온 요청의 처리 방식을 뜻하며, 컴퓨터의 모든 앱을 자동으로 처리한다는 의미는 아닙니다. 앱의 요청이 클라이언트로 전달되는지는 시스템 프록시, 앱 자체 설정 또는 TUN에 따라 달라집니다. 정책 그룹의 자동 선택, 장애 조치, 부하 분산은 첫 연결 단계에서 설정할 필요가 없습니다. 자세한 내용은 정책 그룹 필드를 참고하세요.
3단계: 코어와 시스템 프록시 켜기
클라이언트 기본 화면으로 돌아가 코어가 실행 중인지 확인합니다. 설정을 가져온 뒤 코어를 자동으로 시작하는 클라이언트도 있고 연결 또는 시작 버튼을 눌러야 하는 클라이언트도 있습니다. 설정 오류, 포트 충돌, 코어 시작 실패가 표시되면 먼저 해당 문제를 해결한 다음 시스템 프록시를 켜세요. 시스템 프록시는 앱의 요청을 로컬 수신 주소로 전달합니다. 수신 서비스가 시작되지 않았다면 브라우저는 응답하는 서비스가 없는 포트로 요청을 보냅니다.
‘시스템 프록시’ 스위치를 찾아 켭니다. 설정 페이지, 홈 화면의 바로가기 영역 또는 메뉴 막대 메뉴에 있을 수 있습니다. 처음 켤 때 macOS 또는 클라이언트가 보조 서비스 설치나 네트워크 설정 변경 권한을 요청하면 요청을 시작한 앱과 작업 목적을 확인한 뒤 안내에 따라 진행하세요. 보조 서비스 이름과 권한 부여 방식은 클라이언트마다 다릅니다. 가이드에 맞추기 위해 실제 화면에 없는 버튼을 찾을 필요는 없습니다.
macOS ‘시스템 설정’에서 ‘네트워크’로 이동해 현재 사용하는 Wi-Fi 또는 이더넷 서비스를 선택하고 ‘세부사항’의 ‘프록시’를 엽니다. 이전 버전의 시스템에서는 ‘시스템 환경설정’의 네트워크 고급 설정에 해당 항목이 있을 수 있습니다. 웹 프록시와 보안 웹 프록시의 주소와 포트가 클라이언트 설정과 일치하는지 확인합니다. 클라이언트에서 SOCKS 프록시를 설정했다면 해당 항목도 확인하세요. 흔히 사용하는 로컬 주소는 127.0.0.1이고, 혼합 포트 예시는 7890이지만 실제 설정값을 기준으로 해야 합니다.
확인하는 동안 다른 프록시 도구의 시스템 연결 스위치는 꺼 두세요. 여러 앱이 같은 네트워크 설정을 반복해서 변경하는 일을 막을 수 있습니다. 회사에서 관리하는 프록시, VPN 또는 보안 소프트웨어도 라우팅과 DNS에 영향을 줄 수 있으므로 해당 네트워크의 관리 지침을 따르세요. 확인을 마친 뒤에는 TUN을 켜지 말고 다음 단계에서 브라우저를 먼저 테스트합니다. 이 순서를 따르면 시스템 프록시 문제와 가상 네트워크 인터페이스 문제를 구분하기 쉽습니다.
4단계: 브라우저와 터미널에서 각각 확인
먼저 Safari 또는 시스템 프록시 설정을 사용하는 브라우저에서 접속하려는 HTTPS 웹페이지를 열고, 평소 직접 접속할 수 있는 웹페이지도 열어 비교합니다. 웹페이지가 열리는 것은 첫 번째 확인 단계일 뿐입니다. 클라이언트의 ‘연결’ 또는 ‘로그’ 페이지에서 요청을 새로 발생시킨 뒤 해당 도메인이 기록되는지, 어떤 규칙이 적용되었는지, 어떤 정책 그룹과 출구가 선택되었는지 확인하세요. 연결 기록은 금방 사라질 수 있으므로 필요하면 웹페이지를 새로고침하고 바로 살펴보세요.
브라우저에 별도의 프록시 확장 프로그램이 설치되어 있다면 시스템 설정을 덮어쓰지 않는지 먼저 확인하세요. 직접 연결 규칙이 적용되는 웹사이트는 클라이언트가 정상 작동하더라도 원격 노드를 사용하지 않을 수 있습니다. 따라서 출구 주소가 바뀌지 않았다는 이유만으로 프록시가 작동하지 않는다고 판단하면 안 됩니다. 해당 웹사이트에 어떤 규칙이 적용되었는지 확인해 실제 동작이 설정의 의도와 일치하는지 살펴보세요. 규칙의 순차 적용 방식은 규칙 문법 안내를 참고하세요.
현재 네트워크 서비스의 프록시 항목 조회
‘터미널’을 열고 다음 명령으로 시스템 네트워크 서비스를 읽기 전용으로 조회할 수 있습니다. 프록시 설정은 변경되지 않습니다. 먼저 서비스 이름을 확인한 다음 후속 명령의 Wi-Fi를 현재 서비스의 실제 이름으로 바꾸세요. 조회 결과의 활성화 상태, 서버 주소, 포트가 클라이언트 설정과 일치해야 합니다. 이는 시스템 항목이 기록되었음을 보여 주지만, 원격 노드가 작동한다는 사실까지 입증하지는 않습니다.
networksetup -listallnetworkservices
networksetup -getwebproxy "Wi-Fi"
networksetup -getsecurewebproxy "Wi-Fi"
networksetup -getsocksfirewallproxy "Wi-Fi"명시적 프록시로 로컬 수신과 시스템 연결 구분하기
터미널 도구가 macOS 시스템 프록시를 반드시 사용하는 것은 아닙니다. 아래 명령은 curl이 로컬 HTTP 프록시를 통해 요청하도록 지정해 수신 포트와 이후 연결 경로를 따로 확인합니다. 실행 전에 실제 HTTP 포트 또는 혼합 포트를 확인하세요. 7890이 아니라면 포트를 바꾸면 됩니다. 테스트 대상 도메인은 공개 예시 주소이며 결과는 현재 네트워크, 노드, 대상 서비스의 영향을 받습니다.
curl --proxy http://127.0.0.1:7890 --connect-timeout 10 -I https://example.com/로컬 포트에 연결할 수 없다면 클라이언트로 돌아가 코어와 수신 값을 확인하세요. 로컬 연결은 되지만 원격 요청이 시간 초과되면 노드, 정책 그룹, 대상 네트워크를 확인합니다. 유효한 HTTP 응답을 받았다는 것은 이번 요청이 HTTP 서비스에 도달했다는 뜻이지만, 출구는 연결 기록을 함께 확인해야 합니다. 브라우저는 정상인데 프록시 옵션을 지정하지 않은 curl이 실패한다면 클라이언트를 바로 재설치하기보다 터미널 프록시 설정을 먼저 확인하세요.
현재 터미널 세션에 프록시 설정
이 환경 변수를 지원하는 명령줄 도구에서 프록시를 사용하려면 현재 셸에서 다음 명령을 실행하세요. HTTPS 요청도 HTTP 프록시의 터널링 방식으로 전달되므로 프록시 주소에는 http://를 사용합니다. 이 설정은 현재 셸과 이후에 시작하는 하위 프로세스에만 적용되며 이미 실행 중인 터미널 작업은 자동으로 바뀌지 않습니다. 환경 변수 지원 여부는 도구마다 다를 수 있습니다.
export http_proxy="http://127.0.0.1:7890"
export https_proxy="http://127.0.0.1:7890"
export no_proxy="localhost,127.0.0.1,::1"
curl --connect-timeout 10 -I https://example.com/현재 세션에서 설정이 적용되는지 먼저 확인한 다음 셸 설정 파일에 추가할지 결정하세요. 처음부터 여러 시작 파일에 설정을 추가하면 클라이언트를 종료한 뒤에도 설정이 남을 수 있습니다. 이 단계까지 브라우저 요청, 시스템 프록시 항목, 명시적 프록시 테스트를 각각 확인했습니다. 대상 앱이 여전히 시스템 프록시를 사용하지 않는다면 다음 TUN 추가 절차를 살펴보세요.
필요한 경우 추가: TUN 모드 및 권한
TUN은 가상 네트워크 인터페이스와 라우팅을 통해 요청을 처리하며, 시스템 프록시를 읽지 않는 앱의 트래픽을 다뤄야 하는 경우 등에 유용합니다. ‘규칙 / 전역 / 직접 연결’과는 서로 다른 계층의 설정입니다. TUN은 요청이 코어에 들어가는 방식을 결정하고, 프록시 모드는 코어에 들어온 뒤 출구를 선택하는 방식을 정합니다. TUN 지원 여부, 네트워크 스택, 보조 서비스 설치 방법은 클라이언트와 함께 사용하는 코어에 따라 다릅니다. mihomo 코어를 사용하는 클라이언트도 설정 위치가 서로 다를 수 있습니다.
앞 단계에서 시스템 프록시를 확인한 다음 클라이언트의 네트워크 또는 고급 설정으로 이동해 ‘TUN 모드’ 또는 이에 해당하는 항목을 찾습니다. 서비스 모드나 권한이 필요한 보조 프로그램 설치를 요청하면 클라이언트 안내에 따라 권한을 부여한 뒤 TUN을 켜세요. 인터넷에서 찾은 라우팅 명령을 먼저 직접 복사하지 마세요. 처음에는 클라이언트의 기본 네트워크 스택과 라우팅 설정을 그대로 유지하고, 대상 앱에서 요청을 다시 보낸 뒤 연결 기록에 코어로 들어온 내역이 있는지 확인합니다.
TUN을 켠 뒤 DNS 오류, LAN 기기 연결 문제, 다른 VPN과의 충돌이 발생하면 먼저 TUN을 끄고 검증된 시스템 프록시 상태로 돌아간 다음 한 번에 옵션 하나만 변경하세요. 스위치가 켜져 있다고 해서 모든 트래픽이 처리된다고 단정할 수는 없습니다. 앱 프로토콜, 제외 라우트, 시스템 권한이 실제 결과에 영향을 줍니다. DNS, 라우팅, YAML 구조에 관한 자세한 내용은 YAML 가이드에서 확인할 수 있습니다. 처음 설정할 때 모든 항목을 바꿀 필요는 없습니다.
플랫폼별 안내: Windows 앱 루프백
이 절은 Windows에만 해당합니다. AppContainer 격리 방식을 사용하는 일부 앱은 시스템 제한으로 로컬 루프백 프록시에 접속하지 못할 수 있습니다. 브라우저에서는 프록시가 작동하지만 특정 앱의 연결은 실패하는 식으로 나타납니다. 이는 macOS의 시스템 프록시 권한 문제와 다르므로 Mac 사용자는 UWP 루프백 스위치를 찾거나 Windows 예외 명령을 따라 할 필요가 없습니다.
Windows에서는 먼저 같은 로컬 프록시 포트가 일반 데스크톱 앱에서 작동하는지 확인한 다음 대상 앱이 루프백 제한을 받는지 살펴봅니다. 클라이언트에 ‘루프백 제외’ 또는 비슷한 도구가 있다면 안내에 따라 필요한 권한으로 실행하고, 로컬 프록시에 접속해야 하는 앱에만 예외를 설정하세요. 저장한 뒤 대상 앱을 완전히 종료하고 다시 시작합니다. 클라이언트에 해당 도구가 없어도 모든 Windows 앱에서 프록시를 사용할 수 없는 것은 아닙니다. 루프백 예외를 모든 문제의 해결책으로 여기지 마세요.
루프백 예외는 앱의 로컬 주소 접근 권한만 다루며 구독 가져오기, 노드 선택, 시스템 프록시 설정을 대신하지 않습니다. 예외를 적용해도 문제가 계속되면 앱이 프록시를 읽는지, UDP를 사용하는지, 현재 설정이 해당 트래픽을 허용하는지 차례로 확인하세요. Windows 클라이언트가 필요하면 Windows 다운로드 페이지에서 선택할 수 있습니다. 이미 완료한 Mac 설정을 변경할 필요는 없습니다.
클라이언트 종료 및 네트워크 복구
테스트를 마치고 프록시를 중지하려면 먼저 클라이언트에서 TUN과 시스템 프록시를 끈 다음 클라이언트를 종료하세요. 이렇게 하면 로컬 수신 서비스는 중지됐는데 시스템 네트워크 설정은 이전 포트를 계속 가리키는 상황을 막을 수 있습니다. 기본 창만 닫으면 클라이언트가 메뉴 막대로 숨겨질 수 있으며, 완전히 종료된 것이 아닙니다. 메뉴 막대의 종료 명령으로 실행을 끝내세요. 세부 동작은 클라이언트 설정에 따라 다를 수 있습니다.
클라이언트가 비정상 종료된 뒤 브라우저에서 인터넷에 접속할 수 없다면 현재 네트워크 서비스의 프록시 설정을 열어 로컬 주소를 가리키는 HTTP, HTTPS 또는 SOCKS 프록시가 남아 있는지 확인하세요. 해당 항목이 방금 사용한 클라이언트에서 설정한 것임을 확인한 뒤 관련 항목을 해제합니다. 회사 네트워크에서 요구하는 프록시 주소나 자동 프록시 설정까지 함께 삭제하지 마세요. 터미널 환경 변수를 사용했다면 해당 변수도 지우거나 그 세션을 닫고 터미널을 다시 여세요.
unset http_proxy https_proxy all_proxy no_proxy
unset HTTP_PROXY HTTPS_PROXY ALL_PROXY NO_PROXY~/.zshrc 같은 시작 파일에 변수를 추가했다면 unset만으로는 새 세션에서 다시 불러오는 것을 막을 수 없습니다. 직접 추가한 해당 줄도 삭제해야 합니다. 복구한 뒤 브라우저와 터미널을 각각 테스트하세요. 검증된 설정을 하나 보관하고 이후 구독 업데이트, 규칙 추가, TUN 활성화는 한 번에 하나씩 진행하세요. 설정을 더 바꾸려면 구독 파일 전체를 덮어쓰기보다 설정 덮어쓰기부터 확인하세요.