시작하기 전에 클라이언트를 설치하고 서비스 제공업체가 안내한 구독 링크 또는 YAML 설정 파일을 준비하세요. 클라이언트는 설정을 읽고 연결을 전달하는 역할을 하며, 설치만으로 사용할 수 있는 출구가 생기는 것은 아닙니다. 처음 설정할 때는 약 10분 정도 여유를 두세요. 구독, 계정 권한 또는 네트워크 환경이 준비되지 않았다면 클라이언트 설정을 반복해서 바꾸기보다 먼저 필요한 조건을 해결해야 합니다.
네트워크를 가로채는 다른 프록시나 VPN 도구가 실행 중이라면 먼저 종료하세요. 프록시 주소, 가상 네트워크 어댑터, 라우팅 설정이 서로 충돌할 수 있습니다. 기존 설정을 복사해 두고 운영체제의 원래 프록시 상태도 기록해 두세요. 각 단계에서 한 종류의 설정만 변경하고 결과를 확인한 뒤 다음으로 넘어가면 문제가 생겼을 때 되돌릴 지점을 쉽게 찾을 수 있습니다.
01 · 구독을 가져와 설정 활성화하기
클라이언트를 열고 ‘설정’, ‘구독’ 또는 Profiles 페이지로 이동해 ‘새로 만들기’, ‘추가’ 또는 ‘URL에서 가져오기’를 선택하세요. 유형을 묻는 창이 나타나면 프록시 하나를 새로 만드는 대신 원격 구독 또는 원격 설정을 선택합니다. 알아보기 쉬운 이름을 지정한 다음 서비스 제공업체가 안내한 링크 전체를 URL 입력란에 붙여넣으세요. 이름은 이 기기에서 표시되는 방식에만 영향을 주며 연결할 출구를 결정하지 않습니다.
붙여넣은 뒤 링크의 앞뒤를 먼저 확인하세요. 메신저에서 복사한 내용에는 안내 문구, 줄바꿈, 끝의 문장 부호가 함께 들어갈 수 있습니다. 링크만 남기되 물음표 뒤의 매개변수는 지우거나 바꾸지 마세요. 구독 주소에 접근 자격 증명이 포함될 수 있으므로 전체 링크를 공개 게시판에 올리거나 주소가 보이는 스크린샷을 공유하지 마세요. 도움을 요청할 때는 오류 문구를 남기고 주소의 민감한 부분을 가리세요.
저장, 가져오기 또는 다운로드를 눌러 요청이 완료될 때까지 기다리세요. 정상적으로 처리되면 설정 목록에 새 항목이 표시되고 이름, 업데이트 시간 또는 다운로드 상태가 나타납니다. 해당 항목의 ‘사용’, ‘활성화’를 누르거나 선택 표시를 해 현재 설정으로 지정하세요. 저장한 뒤 자동으로 전환되지 않는 클라이언트도 있습니다. 목록에 항목이 추가된 것만으로 실행 중인 코어가 설정을 읽었다고 볼 수는 없습니다.
프록시 그룹이 표시되는지 확인하기
‘프록시’ 또는 Proxies 페이지로 이동해 선택 가능한 프록시 그룹과 구성원이 표시되는지 확인하세요. 프록시 이름은 설정 제공자가 정하므로 반드시 PROXY라고 표시되는 것은 아닙니다. DIRECT, REJECT 같은 기본 항목만 보인다면 설정 페이지로 돌아가 현재 선택된 항목을 확인하고 가져오기 안내도 살펴보세요. 원격 프록시 제공자는 별도로 다운로드해야 할 수 있으므로 기본 설정을 가져왔다고 해서 모든 원격 리소스가 로드된 것은 아닙니다.
로컬 파일을 사용한다면 같은 페이지에서 ‘파일 가져오기’를 선택하고 실제 .yaml 또는 .yml 파일을 찾아 활성화하세요. 파일 확장자만 YAML로 바꿔도 유효한 설정이 되지는 않습니다. 웹페이지, 로그인 안내, 오류 페이지는 설정 파일이 아닙니다. 파일에는 실제 프록시 정보 또는 프록시를 불러올 수 있는 proxy-providers 정의가 있어야 합니다. 포트와 규칙만 있는 조각으로는 보통 프록시 연결을 설정할 수 없습니다.
가져오기에 실패하면 먼저 오류 유형을 확인하세요. 연결 시간 초과는 요청이 정상적으로 완료되지 않았다는 뜻이며, 인증 실패라면 구독 권한을 확인해야 합니다. 파싱 오류가 발생했다면 제공된 설정 형식이 현재 코어와 호환되는지 확인하세요. 개인 구독 링크를 출처가 불분명한 온라인 변환 사이트에 입력하지 마세요. 링크 형식과 변환 시 주의사항은 용어집의 구독 및 설정 파일 설명을 참고하고, 구체적인 오류 해결 방법은 도움말 센터에서 확인하세요.
02 · 규칙 모드와 출구 선택하기
방금 가져온 설정을 활성화한 상태로 유지하고 ‘프록시’ 또는 ‘모드’ 페이지에서 ‘규칙 / 전역 / 직접 연결’ 옵션을 찾으세요. 처음 설정할 때는 ‘규칙’을 선택합니다. 이에 해당하는 코어 설정은 mode: rule입니다. 설정에 정의된 규칙에 따라 연결을 직접 연결하거나 정책 그룹에 전달하거나 차단합니다. 모드는 트래픽 분기 방식만 정하며 다른 앱의 트래픽을 클라이언트로 전달하지는 않습니다.
그다음 설정에서 출구를 선택하는 역할을 하는 정책 그룹을 찾으세요. ‘프록시 선택’, ‘노드 선택’ 등 다른 이름으로 표시될 수 있습니다. 그룹을 펼쳐 사용 가능한 프록시를 선택하세요. 구성원이 또 다른 정책 그룹이라면 해당 그룹에서 현재 선택된 출구도 확인합니다. 처음 연결을 검증할 때는 테스트 결과와 출구를 쉽게 연결할 수 있도록 직접 선택할 수 있는 항목을 사용하세요. 여러 트래픽 분할 그룹을 한꺼번에 바꾸지 마세요.
일부 설정에서는 자동 테스트 그룹이 기본으로 선택되어 있습니다. 그대로 사용해도 되지만, 테스트 결과는 클라이언트에서 지정된 테스트 주소까지 확인한 값일 뿐 대상 웹사이트에 반드시 접속할 수 있다는 뜻은 아닙니다. 클라이언트에 연결 테스트 버튼이 있다면 한 번 실행해 시간 초과나 명확한 오류가 있는지 살펴보세요. 테스트 후에도 실제 접속을 확인해야 하며, 테스트 수치 하나만으로 모든 앱의 트래픽이 처리된다고 판단해서는 안 됩니다.
모드와 트래픽 가로채기 스위치 구분하기
| 모드 | 연결 처리 방식 | 처음 사용할 때 권장하는 방법 |
|---|---|---|
| 규칙 rule | 설정에 정의된 규칙에 따라 연결을 처리합니다. | 일상적인 사용과 이 가이드의 기본 설정으로 권장합니다. |
| 전역 global | 코어에 전달된 연결을 전역 정책으로 처리합니다. | 규칙의 영향을 비교해야 할 때만 잠시 사용하세요. |
| 직접 연결 direct | 코어에 전달된 연결을 대상에 직접 연결합니다. | 특정 상황의 비교에 사용하며, 트래픽 가로채기를 끄는 것과는 다릅니다. |
‘전역’을 선택해도 원래 클라이언트를 우회하던 앱의 연결이 자동으로 코어에 전달되지는 않습니다. 브라우저가 시스템 프록시를 사용하지 않는다면 전역 모드로 바꾸는 것만으로는 트래픽 가로채기 문제가 해결되지 않습니다. 마찬가지로 ‘직접 연결’을 선택해도 시스템 프록시 설정이나 가상 네트워크 어댑터가 제거되는 것은 아닙니다. 트래픽 가로채기를 완전히 중지하려면 모드만 바꾸지 말고 해당 스위치를 끄세요.
규칙 모드에서 특정 대상의 연결 경로가 예상과 다르다면 규칙을 바로 삭제하지 말고 먼저 현상을 기록하세요. 다음 단계의 연결 페이지에서 적용된 규칙을 확인하면 규칙 선택 문제인지 트래픽 가로채기 문제인지 판단할 수 있습니다. 지금은 규칙 모드가 선택되어 있고 출구 그룹이 명확하게 지정되어 있는지만 확인한 뒤 연결 단계로 넘어가세요. 규칙 순서, 정책 그룹 중첩, MATCH의 자세한 동작은 전체 문서의 설정 항목을 참고하세요.
03 · 시스템 프록시 또는 VPN 연결 켜기
먼저 클라이언트의 홈 또는 개요 페이지로 돌아가 설정을 불러온 뒤 코어가 실행 중인지 확인하세요. ‘코어 시작’과 ‘시스템 프록시’ 스위치가 따로 있다면 코어를 먼저 시작하고 시스템 프록시를 켭니다. 연결 버튼 하나만 있다면 클라이언트 안내에 따라 진행하고 로그에서 시작 실패가 없는지 확인하세요. 이 단계에서는 여러 네트워크 가로채기 도구를 동시에 켜지 말고 문제를 확인하기 위해 시스템 방화벽을 끄지도 마세요.
데스크톱: 먼저 시스템 프록시 확인하기
Windows, macOS, 데스크톱 환경의 Linux 클라이언트에는 보통 ‘시스템 프록시’ 스위치가 있습니다. 이 기능을 켜면 운영체제의 프록시 설정을 따르는 앱이 로컬 수신 포트로 요청을 전달합니다. 클라이언트 설정에서 실제 주소와 포트를 확인하세요. 예를 들어 127.0.0.1:7890처럼 표시될 수 있습니다. 이는 흔히 사용하는 설정일 뿐이므로 현재 클라이언트에 표시된 값을 기준으로 하세요. 가이드의 숫자와 맞추려고 포트를 임의로 바꾸지 마세요.
클라이언트에서 포트가 이미 사용 중이라고 표시되면 다른 프록시 클라이언트를 종료한 뒤 코어를 다시 시작하세요. 시작 로그에 address already in use가 나타난다면 시스템 프록시 스위치가 켜져 보여도 로컬 프록시 서비스가 작동한다고 볼 수 없습니다. 수신이 정상적으로 시작된 것을 확인한 뒤 브라우저 창을 새로 열어 테스트하세요. 일부 앱은 기존 연결을 계속 사용할 수 있으므로 필요한 경우 페이지를 새로고침하는 데 그치지 말고 앱을 완전히 종료한 다음 다시 시작하세요.
Linux에서 데스크톱 프록시 설정을 앱이 따르는지는 데스크톱 환경과 앱 구현에 따라 다릅니다. 터미널 프로그램도 시스템 프록시를 읽지 않을 수 있습니다. 처음 연결을 확인할 때는 프록시 설정을 지원하는 브라우저를 사용하고, 모든 터미널 도구의 동작을 기준으로 판단하지 마세요. 서버, 라우터 또는 systemd 서비스 배포는 이 그래픽 인터페이스 입문 과정의 범위에 포함되지 않습니다. 관련 설정은 Linux 설치 및 배포 항목을 참고하세요.
모바일: 시스템 VPN 권한 승인하기
Android와 iOS에서는 클라이언트의 시작 또는 연결 버튼을 누르면 시스템에서 VPN 연결을 만들거나 VPN 구성을 추가할지 묻는 경우가 많습니다. 사용 중인 클라이언트에서 보낸 요청인지 확인한 다음 시스템 안내에 따라 승인하세요. 클라이언트로 돌아와 연결 상태를 확인합니다. 권한 요청을 취소하면 설정을 선택했더라도 네트워크 트래픽 처리가 시작되지 않습니다. 상태 표시줄의 시스템 아이콘은 터널이 켜졌다는 뜻일 뿐, 원격 출구가 작동한다는 보장은 아닙니다.
시스템에서 다른 VPN을 사용 중이라면 먼저 연결을 끊은 뒤 현재 클라이언트를 시작하세요. 두 도구가 시스템 VPN 채널을 두고 충돌할 수 있습니다. 처음 테스트할 때는 클라이언트를 포그라운드에 둔 채 접속을 확인하세요. 포그라운드에서는 정상인데 백그라운드로 전환했을 때만 연결이 끊기는 경우에 배터리 관리와 백그라운드 실행 권한을 확인하면 됩니다. 이런 백그라운드 제한을 구독 만료로 오해해 반복해서 다시 가져오지 마세요.
TUN은 언제 켜야 하나요?
데스크톱에서는 먼저 시스템 프록시로 재현 가능한 테스트 결과를 확인하세요. 시스템 프록시 설정을 따르지 않는 앱이나 특정 유형의 트래픽까지 처리해야 할 때 TUN을 고려하면 됩니다. TUN은 보통 가상 네트워크 인터페이스, 라우팅, DNS 처리를 포함하며 관리자 권한이나 클라이언트 서비스 지원이 필요할 수 있습니다. 클라이언트의 서비스 설치 안내에 따라 설정하고 스위치 색만 보고 설치가 완료됐다고 판단하지 마세요.
TUN을 처음 켤 때는 기존 시스템 프록시 상태를 기록하고 해당 클라이언트의 병행 사용 안내를 따르세요. TUN, DNS, 라우팅, 모드를 한꺼번에 바꾸지 마세요. 활성화 후 기본 네트워크가 끊기면 먼저 TUN을 끄고 이미 확인한 시스템 프록시 방식으로 돌아가세요. 데스크톱 TUN과 모바일 VPN 권한 화면은 이름이 비슷해도 실제 구현은 다릅니다. 자세한 원리는 네트워크 트래픽 처리 방식 용어를 참고하세요.
04 · 접속 및 연결 기록 확인하기
앱과 클라이언트 양쪽에서 상태를 확인해야 합니다. 먼저 트래픽 가로채기를 끈 상태에서 현재 네트워크로 평소 이용하는 사이트에 접속할 수 있는지 확인하세요. 기본 네트워크부터 문제가 있다면 Wi-Fi, 모바일 데이터 또는 네트워크 로그인 상태를 먼저 점검합니다. 그런 다음 프록시 연결을 다시 켜고 확인할 페이지를 엽니다. 캐시된 페이지가 아니라 새 요청으로 테스트하세요.
페이지가 로드되면 바로 클라이언트의 ‘연결’ 또는 Connections 페이지로 돌아가 방금 접속한 도메인을 찾으세요. 새 요청이 빠르게 끝났다면 페이지를 다시 새로고침하고 로그도 함께 확인합니다. 대상이 표시되는지, 어떤 규칙이 적용됐는지, 어떤 정책 또는 출구로 전달됐는지 점검하세요. 규칙 모드에서는 일부 사이트에 DIRECT가 적용되는 것이 정상적인 분기일 수 있으며, 클라이언트 전체가 작동하지 않는다는 뜻은 아닙니다.
증상에 따라 점검 범위 좁히기
대상 연결 기록이 전혀 없다면 앱이 시스템 프록시를 사용하는지, 코어가 실제로 수신 중인지, 모바일 VPN 연결이 유지되는지 먼저 확인하세요. 요청이 클라이언트에 들어오지 않았을 수 있으므로 이 단계에서 출구부터 바꾸지는 마세요. 기록은 있지만 연결 경로가 예상과 다르면 소프트웨어를 다시 설치하는 대신 현재 모드, 적용된 규칙, 정책 그룹 선택을 확인하세요.
예상한 정책이 적용됐는데도 시간 초과, 연결 거부 또는 핸드셰이크 오류가 발생한다면 선택한 출구의 작동 여부, 구독 권한, 기기 시간을 확인하세요. 한 번에 출구 하나만 바꾸고 같은 대상에 다시 연결해 전후 결과를 기록합니다. 특정 사이트에서만 문제가 생긴다면 대상 사이트 자체의 상태도 고려하세요. 한 사이트의 성공이나 실패만으로 전체 네트워크 연결을 판단하지 마세요.
선택 사항: 로컬 프록시를 직접 지정해 테스트하기
데스크톱에서는 아래 명령으로 로컬 프록시 서비스와 앱의 프록시 설정을 구분해 확인할 수 있습니다. 이 명령은 로컬 HTTP 프록시를 직접 사용하므로 브라우저가 시스템 설정을 읽는지에 영향을 받지 않습니다. 실행 전에 포트를 클라이언트의 실제 HTTP 또는 mixed 수신 포트로 바꾸세요. SOCKS 수신만 켜져 있다면 이 HTTP 프록시 매개변수를 그대로 사용하지 마세요.
curl --proxy http://127.0.0.1:7890 --head --max-time 15 https://example.com/
Windows PowerShell에서는 예전 환경의 동명 별칭이 매개변수 해석에 영향을 주지 않도록 명령 앞에 curl.exe를 붙이는 것이 좋습니다. HTTP 응답 헤더가 반환되면 지정한 로컬 프록시를 통한 요청이 대상 응답을 받았다는 뜻입니다. 다만 원격 출구를 사용했는지는 클라이언트 연결 기록을 확인해야 합니다. 규칙에 따라 해당 대상이 직접 연결됐을 수도 있습니다. 로컬 주소에 연결할 수 없다면 DNS를 바로 바꾸지 말고 먼저 수신 포트를 확인하세요.
명령은 성공하지만 브라우저가 실패한다면 브라우저 자체의 프록시 확장 프로그램, 별도 프록시 설정, 기존 연결을 확인하세요. 브라우저는 성공하지만 다른 앱이 실패한다면 해당 앱이 시스템 프록시를 지원하는지 확인하고 필요할 때 TUN을 검토합니다. 외부 IP 조회는 참고 자료로만 사용하세요. 규칙 분할에서는 조회 사이트마다 다른 출구를 사용할 수 있으므로 IP가 바뀌지 않았다는 사실만으로 프록시가 작동하지 않는다고 단정할 수 없습니다.
재현 가능한 정상 상태 저장하기
테스트 페이지에 접속할 수 있고 연결 기록도 예상과 일치하면 현재 모드와 트래픽 처리 방식을 유지하세요. 사용 중인 설정 이름, 실제 수신 포트, 선택한 정책 그룹을 기록해 두면 다음에 문제를 해결하기 쉽습니다. 종료할 때는 시스템 프록시나 VPN 연결을 먼저 끈 다음 클라이언트를 종료하세요. 특히 시스템 프록시 주소를 직접 설정한 기기에서는 중지된 포트를 가리키는 설정이 남지 않았는지 확인해야 합니다.
구독 내용이 변경되면 설정 페이지에서 업데이트한 뒤 현재 설정이 계속 활성화되어 있는지 확인하고 이 절의 검증을 다시 진행하세요. 기본 테스트가 끝나기 전에 복잡한 규칙을 추가하지 마세요. 업데이트 실패, UWP 앱의 프록시 미적용, 일부 프로그램만 인터넷에 연결되지 않는 문제는 도움말 센터에서 증상별로 확인하세요. 설정을 장기적으로 관리하려면 전체 문서를 이어서 읽어보세요.