V2Ray 고급 설정 가이드

1. 구독 그룹 및 서버 필터링

구독은 서버 설정을 업데이트하는 출처이고, 그룹은 클라이언트에서 출처와 항목을 정리하는 방식입니다. 두 개념을 구분해야 합니다. 서버 목록에 그룹이 표시된다고 해서 해당 그룹이 라우팅 규칙에서 참조되는 것은 아니며, 그룹을 선택해 보고 있다고 해서 그 안의 서버를 실제로 사용 중이라는 뜻도 아닙니다. 정리를 시작하기 전에 현재 선택된 서버, 연결된 구독, 적용 중인 라우팅 모드를 확인하고 연결이 되는 설정을 하나 기록해 두세요. 목록을 정리한 뒤에도 문제를 비교할 기준이 필요합니다.

출처별로 그룹을 만들고 용도에 따라 필터링

v2rayN의 구독 그룹 설정에서 각 출처를 알아볼 수 있는 설명과 해당 주소를 입력하세요. 임시 서버 이름을 그룹 이름으로 쓰기보다는 “일상 연결”, “테스트 환경”처럼 출처나 용도를 나타내는 이름이 좋습니다. 저장한 뒤 해당 그룹을 업데이트하고 새 항목이 예상한 위치에 들어왔는지 확인하세요. 직접 가져온 링크는 별도 그룹으로 관리하는 편이 안전합니다. 그렇지 않으면 구독 항목을 정리하다 보관해야 할 수동 설정까지 삭제할 수 있습니다.

구독 주소에는 보통 접근 자격 정보가 포함되어 있으므로 민감 정보로 취급하세요. 전체 주소가 보이는 스크린샷이나 공개 문의, 공유 문서에 올리지 말고, 테스트를 위해 서로 다른 출처의 주소를 바꿔 넣지도 마세요. 업데이트에 실패했다면 먼저 구독 내용을 다운로드하는 단계에서 실패했는지, 내용을 파싱하는 단계에서 실패했는지 확인하세요. 전자는 네트워크, 인증서 또는 권한 문제일 수 있고, 후자는 구독 형식과 클라이언트의 호환성 문제일 수 있습니다. 그룹 이름은 로컬에서 구분하기 위한 표시일 뿐이므로 설명을 바꿔도 만료된 주소가 복구되지는 않습니다.

목록 검색과 저장되는 필터를 구분

서버 목록의 검색창은 보통 현재 화면에 표시되는 항목만 바꿉니다. 반면 구독 그룹의 필터 설정은 업데이트 후 남기거나 표시할 서버에 영향을 줄 수 있습니다. 설정하기 전에 안내 문구를 읽고 서버 설명, 주소 또는 다른 속성 중 무엇을 기준으로 필터링하는지 확인하세요. 실제로 존재하는 짧은 키워드 하나로 먼저 테스트하고 결과를 확인한 다음 조건을 추가하세요. 일반 키워드만 받는 입력란에 범용 정규식을 넣거나, 모든 클라이언트가 같은 방식으로 매칭한다고 가정하지 마세요.

특정 입력란이 정규식을 지원한다고 명시되어 있다면 (?i)(test|backup)으로 대소문자를 구분하지 않는 후보 키워드를 지정할 수 있습니다. 단, 이 형식을 지원하는지는 해당 입력란에서 사용하는 정규식 엔진에 따라 다릅니다. 지원하지 않으면 화면에서 제공하는 일반 텍스트 필터를 사용하세요. 포함 조건과 제외 조건을 각각 검증하고, 공백, 전각 기호, 설명에 들어간 특수 문자도 확인하세요. 조건이 너무 넓으면 관련 없는 항목이 남고, 너무 좁으면 “업데이트 성공, 목록은 비어 있음” 상태가 될 수 있습니다.

업데이트 후 설정 항목이 같은지 확인

구독을 업데이트하면 서버가 추가, 삭제 또는 이름 변경될 수 있으며, 이름이 같아도 연결 매개변수가 완전히 같다는 보장은 없습니다. 업데이트 후에는 설명뿐 아니라 프로토콜, 서버 주소, 포트, 전송 방식도 확인하세요. 계속 사용해야 하는 항목이라면 업데이트 후 클라이언트가 선택 상태를 어떻게 유지하는지 확인해야 합니다. 기존 항목이 사라졌다면 목록에서 다른 항목이 강조 표시된다는 이유만으로 대체 설정으로 전환되었다고 판단하지 마세요. 대상 서버를 다시 선택하고 새 연결을 만들어 실제 동작을 확인하세요.

항목이 중복되면 먼저 같은 출처에서 중복 제공된 것인지, 여러 그룹에 같은 서버가 각각 들어 있는지 확인하세요. 중복 항목을 삭제하기 전에 원래 구독 관계를 유지해야 다음 업데이트 때 다시 생기거나 전송 매개변수가 다른 항목을 잘못 삭제하는 일을 막을 수 있습니다. Android에서는 그룹 및 필터 메뉴 위치가 다를 수 있지만 기본 원칙은 같습니다. 출처 하나로 범위를 좁힌 뒤 항목 내용을 확인하고 마지막으로 연결을 테스트하세요. 이름이 비슷하다는 이유만으로 여러 항목을 한꺼번에 삭제하면 실제 설정 차이를 놓치기 쉽습니다.

2. 라우팅 규칙 실전

라우팅은 코어에 들어온 연결을 처리합니다. 시스템 프록시는 앱이 연결을 로컬 진입점으로 보낼지를 결정하고, 라우팅은 들어온 연결에 사용할 아웃바운드를 선택합니다. 두 계층은 서로 대체할 수 없습니다. 설정하기 전에 앱, 진입점, 대상 식별, 규칙 매칭, 아웃바운드 순으로 실제 경로를 그려 보세요. 앱이 시스템 프록시를 사용하지 않는다면 도메인 규칙을 수정해도 앱의 네트워크 연결 방식은 달라지지 않습니다. 두 설정의 차이는 시스템 프록시와 라우팅 모드 비교를 함께 참고하세요.

규칙은 순서대로 매칭되므로 구체적인 조건을 앞에 배치

일반적으로 규칙은 순서대로 확인하며, 조건에 맞으면 해당 출구가 선택됩니다. 따라서 예외 규칙은 포괄적인 규칙보다 앞에 두세요. 기본 순서는 명확한 업무 예외, 차단할 범주, 로컬 네트워크 주소, 자주 사용하는 직접 연결 범위, 마지막으로 기본 출구가 적절합니다. 규칙을 “직접 연결, 프록시, 차단” 세 가지 큰 범주로만 나눠 정리하지 마세요. 앞선 규칙이 대상을 이미 처리했다면 뒤의 세부 규칙은 올바르게 작성했더라도 적용되지 않습니다.

한 규칙에 도메인, 포트, 네트워크 유형 등 서로 다른 필드를 함께 입력하면 보통 모든 필드가 동시에 일치해야 합니다. 반면 한 도메인 배열 안의 여러 항목은 후보 매칭 조건입니다. “특정 도메인 또는 특정 포트”를 한 규칙에 넣으면 예상과 달리 교집합으로 처리될 수 있습니다. 합집합 조건이 필요하면 규칙을 나누세요. 수정하기 전에 도메인으로 판단할지, DNS 조회 후의 주소로 판단할지 먼저 정해야 합니다. 이에 따라 DNS 조회가 필요한지도 달라집니다.

최소 설정으로 직접 연결과 차단 구성

아래는 Xray / V2Fly에서 흔히 쓰이는 필드 형식의 라우팅 설정 예시이며, 전체 실행 설정은 아닙니다. 기존 설정에 direct, block, 기본 프록시 아웃바운드가 이미 있고, 해당 분류가 포함된 규칙 리소스가 설치되어 있어야 합니다. 여기서 AsIs는 IP 규칙을 위해 아직 주소를 얻지 못한 도메인을 적극적으로 조회하지 않는다는 뜻입니다. 이미 IP 주소 형태로 들어온 대상은 IP 규칙에 매칭될 수 있습니다.

{
  "routing": {
    "domainStrategy": "AsIs",
    "rules": [
      {
        "type": "field",
        "domain": ["geosite:category-ads-all"],
        "outboundTag": "block"
      },
      {
        "type": "field",
        "ip": ["geoip:private"],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "domain": ["geosite:cn"],
        "outboundTag": "direct"
      }
    ]
  }
}

이 예시에는 final이라는 이름의 규칙 필드가 없습니다. 이 필드는 이러한 JSON 라우팅에서 범용 키워드가 아니기 때문입니다. 규칙에 매칭되지 않으면 보통 아웃바운드 목록의 첫 번째 항목이 사용되며, GUI 클라이언트가 자체 폴백 규칙을 생성할 수도 있습니다. 화면에 표시되는 축약 이름만 보지 말고 실제로 생성된 설정을 확인하세요. 나머지 TCP와 UDP 연결을 프록시로 보내려면 마지막에 해당 네트워크 규칙을 추가할 수 있지만, 출구 설정과 UDP 지원 여부가 맞는지 확인해야 합니다.

도메인 식별과 규칙 리소스 확인

도메인 규칙이 적용되려면 코어가 대상 도메인을 알아야 합니다. HTTP 또는 SOCKS 진입점을 통해 도메인을 전달하는 경우와 앱이 시스템에서 먼저 도메인을 조회한 뒤 IP 주소를 전달하는 경우는 다릅니다. 트래픽 스니핑은 일부 프로토콜 데이터에서 도메인을 복원할 수 있지만 모든 트래픽을 식별하지는 못합니다. 규칙이 맞아 보이는데도 적용되지 않는다면 같은 도메인의 표기만 계속 추가하지 말고 로그에 기록된 대상 형식부터 확인한 다음 스니핑 설정을 살펴보세요.

geosite와 geoip는 해당 리소스 파일과 분류에 의존합니다. 리소스 파일이 없거나 현재 파일에 분류가 포함되지 않으면 시작에 실패하거나 설정 검사에서 오류가 발생할 수 있습니다. 클라이언트가 제공하는 리소스 관리 메뉴를 이용해 파일 위치가 실제 코어와 일치하는지 확인하세요. 임의의 작업 디렉터리에 파일을 넣는 것만으로는 충분하지 않습니다. 규칙 범주를 추가할 때마다 재현 가능한 대상 하나를 선택해 새 연결을 만들고 어떤 출구에 매칭되는지 기록하세요. 규칙이 많다고 분기 정확도가 높아지는 것은 아닙니다.

3. DNS 설정 최적화

DNS 설정에서는 세 가지를 확인해야 합니다. 누가 조회를 요청하는지, 어느 리졸버로 요청을 보내는지, 리졸버까지의 연결이 어떤 경로를 사용하는지입니다. 시스템 DNS, 앱 내장 DNS, 코어 DNS는 서로 다른 계층이므로 “DNS 켜기” 하나로 모두 설명할 수 없습니다. 설정을 바꾸기 전에 해결하려는 문제가 조회 실패인지, 현재 출구에 적합하지 않은 결과인지, 라우팅에서 도메인을 확인할 수 없는 문제인지 구분하세요. 조회가 어디에서 발생하는지 알아야 시스템, 클라이언트, 앱 중 무엇을 수정해야 할지 판단할 수 있습니다.

일반 DNS부터 확인한 뒤 도메인별 서버 설정

처음에는 동작을 관찰하기 쉬운 일반 DNS 설정 하나를 유지하세요. 서버 도메인과 일반 사이트 도메인이 모두 조회되는지 확인한 뒤 도메인별 DNS 서버를 추가하면 됩니다. 아래는 코어 DNS 설정의 일부입니다. 특정 도메인은 우선 한 DNS 서버로 보내고, 나머지 조회에는 다른 서버를 사용할 수 있습니다. 이 설정만으로 DNS 요청이 자동으로 프록시를 통과하거나 모든 앱의 시스템 DNS를 제어하는 것은 아닙니다. 사용하기 전에 DNS 서버에 현재 네트워크로 접근할 수 있는지, 기기가 속한 환경의 관리 정책에 맞는지도 확인하세요.

{
  "dns": {
    "servers": [
      {
        "address": "223.5.5.5",
        "domains": ["geosite:cn"]
      },
      "1.1.1.1"
    ]
  }
}

domains가 지정된 서버는 해당 도메인을 우선 매칭하지만, 매칭되지 않았을 때의 시도 방식, 실패 후 폴백, 결과 필터링은 코어 버전과 다른 필드의 영향을 받습니다. 우선 매칭 설정을 엄격한 격리로 이해해서는 안 됩니다. 폴백을 막아야 한다면 현재 코어가 지원하는 폴백 옵션을 확인하고 로그로 동작을 검증하세요. 특정 클라이언트 화면의 “원격 DNS”라는 이름이 모든 코어에서 공통으로 사용하는 JSON 필드라고 가정하지 마세요.

라우팅용 DNS 조회와 아웃바운드용 DNS 조회 구분

라우팅 계층의 domainStrategy는 IP 규칙 매칭을 위해 DNS 조회를 할지 결정합니다. 직접 연결 아웃바운드의 같은 이름 필드는 직접 연결 대상의 조회 및 연결 방식을 제어하므로 위치와 역할이 다릅니다. 예를 들어 라우팅에서 IPIfNonMatch를 사용하면 도메인 규칙에 매칭되지 않은 뒤 대상을 조회해 IP 규칙을 적용할 수 있습니다. 그렇다고 모든 연결이 특정 원격 리졸버를 사용한다는 뜻은 아닙니다. 전략을 바꾼 뒤에는 규칙 매칭과 DNS 요청 증가 여부를 함께 살펴보세요.

프록시 서버 자체의 도메인을 조회할 때는 시작 순서에 특히 유의해야 합니다. DNS 서비스에 접근하려면 먼저 프록시를 거쳐야 하는데 프록시 연결도 같은 DNS 서비스에 의존한다면 순환 의존이 발생합니다. 서버 도메인에는 독립적으로 완료할 수 있는 조회 경로를 사용하거나 출처가 명확하고 지속적으로 관리할 수 있는 서버 주소 설정을 사용하세요. 임시 조회 결과를 장기간 고정해 도메인 관리를 대신하지 마세요. 서버 주소가 바뀌면 설정을 수정하지 않았는데도 연결이 실패할 수 있습니다.

캐시, 듀얼 스택, 앱 자체 DNS

DNS를 수정한 뒤에도 브라우저, 운영체제, 코어에 이전 결과가 남아 있을 수 있고 기존 연결은 즉시 다시 조회되지 않습니다. 테스트할 때는 대상 앱의 기존 연결을 닫고, 필요하면 시스템에서 제공하는 방법으로 캐시를 비운 다음 새 요청을 보내세요. IPv4와 IPv6 결과도 따로 확인해야 합니다. IPv6 주소가 반환되어도 선택한 출구나 현재 네트워크에서 연결할 수 없다면 DNS 오류가 아니라 연결이 지연되다가 복구되는 것처럼 보일 수 있습니다.

앱에 내장된 암호화 DNS는 시스템 DNS 경로를 우회할 수 있으므로 시스템 DNS만 수정하면 기대한 변화가 나타나지 않을 수 있습니다. TUN 환경에서도 모든 암호화 DNS 요청을 포트 규칙으로 식별할 수 있다고 가정하지 마세요. 제어 가능한 테스트에서 앱 자체 DNS를 잠시 끄고 시스템 경로의 동작을 확인한 뒤 호환 설정이 필요한지 판단하세요. 기업 도메인, 로컬 네트워크 기기 이름, 분리 DNS를 사용하는 환경에서는 기존 조회 경로를 유지해야 합니다. 내부 이름을 알지 못하는 공용 리졸버로 보내지 마세요.

4. TUN 모드와 시스템 트래픽 가로채기

TUN은 가상 네트워크 인터페이스로 시스템의 IP 트래픽을 받아 HTTP 또는 SOCKS 프록시를 설정하기 어려운 앱에 적합합니다. 시스템 프록시와의 차이는 진입 계층에 있으며, TUN을 켜면 모든 트래픽이 반드시 프록시를 통과한다는 뜻은 아닙니다. TUN에 들어온 연결도 라우팅 규칙을 거치므로 로컬 네트워크, 직접 연결, 차단 설정은 계속 적용될 수 있습니다. 클라이언트의 TUN 기능은 별도 네트워크 구성 요소로 구현될 수도 있습니다. 따라서 현재 Xray 또는 V2Fly 설정에 같은 TUN 필드가 기본으로 포함되어 있다고 단정하지 마세요.

TUN 적용 전 기준 상태 확인

TUN을 켜기 전에 시스템 프록시 모드에서 서버 연결, 일반 도메인 조회, 기본 라우팅이 예상대로 동작하는지 확인하세요. 그런 다음 시스템 네트워크를 가로챌 수 있는 다른 도구를 끄고 현재 네트워크 인터페이스, 기본 게이트웨이, DNS 상태를 기록한 뒤 TUN을 켜세요. 첫 테스트에서는 필요한 가로채기 옵션만 설정하고 프로세스 규칙, 복잡한 제외 목록, FakeDNS를 한꺼번에 추가하지 마세요. 문제가 발생하면 진입 방식이 바뀌어 생긴 것인지 기존 아웃바운드 설정의 문제인지 구분할 수 있습니다.

권한 문제와 네트워크 문제는 따로 처리해야 합니다. 데스크톱에서는 관리자 권한, 가상 인터페이스 생성 권한 또는 보조 구성 요소 사용 허가가 필요할 수 있습니다. Android 클라이언트는 보통 시스템 VPN 권한을 받아 앱 트래픽을 가로챕니다. 권한을 승인받았다는 것은 시스템에서 진입점을 만들 수 있다는 뜻일 뿐, 트래픽이 원격 서버까지 정상적으로 전달된다는 뜻은 아닙니다. 화면에 시작 실패가 표시되면 진입점이 생성되기 전부터 서버 프로토콜을 계속 바꾸지 말고 권한, 구성 요소 파일, 인터페이스 충돌을 먼저 확인하세요.

루프를 방지하고 로컬 네트워크 연결 유지

프록시 구성 요소의 외부 연결이 같은 TUN 진입점으로 다시 들어오지 않도록 해야 합니다. 그렇지 않으면 루프가 발생해 연결이 계속 재시도되거나 로그가 빠르게 반복될 수 있습니다. 클라이언트는 보통 자동 라우팅과 자체 트래픽 제외를 처리하지만 사용자 지정 네트워크 설정이 기본 동작을 깨뜨릴 수 있습니다. TUN을 켠 뒤 시스템 전체의 네트워크 연결이 끊기면 먼저 TUN을 종료해 네트워크를 복구하고 자동 라우팅, 인터페이스 바인딩, 제외 설정을 확인하세요. 네트워크가 끊긴 상태에서 여러 네트워크 구성 요소를 동시에 다시 설치하지 마세요.

로컬 네트워크 연결에는 사설 주소, 멀티캐스트 검색, 브로드캐스트, 로컬 DNS도 관련됩니다. 라우팅에 사설 주소 직접 연결 규칙을 추가하면 일반적인 주소 접근에는 도움이 되지만, 모든 기기 검색 프로토콜이 트래픽 가로채기 환경에서도 작동한다는 보장은 없습니다. 테스트할 때는 게이트웨이나 알고 있는 기기에 주소로 먼저 연결한 다음 이름 조회와 자동 검색을 확인하세요. 주소로는 접속되지만 이름으로 실패한다면 DNS를 먼저 확인하세요. 자동 검색만 실패한다면 멀티캐스트와 앱의 기기 검색 방식을 확인해야 합니다.

DNS와 UDP를 단계별로 확인

TUN이 UDP를 받을 수 있다고 해서 선택한 서버나 프로토콜 경로가 해당 연결을 전달할 수 있다는 뜻은 아닙니다. 일반 웹 페이지, UDP에 의존하는 앱, 로컬 네트워크 연결을 각각 테스트하세요. 브라우저에서 페이지 하나를 여는 것으로 모든 기능을 확인할 수는 없습니다. 특정 앱만 실패하면 앱 자체 DNS 사용 여부, 특수 목적 포트, 다른 네트워크 인터페이스 사용 여부를 확인한 뒤 가로채기 범위, DNS 경로, 필요한 기능을 지원하는 기존 아웃바운드 중 무엇을 조정할지 결정하세요.

테스트를 마치면 먼저 TUN을 끄고 가상 경로와 DNS가 복구되었는지 확인한 뒤 시스템 프록시가 필요한 상태인지 살펴보세요. 비정상 종료 후 네트워크가 복구되지 않으면 클라이언트를 다시 열고 가로채기 기능을 정상적으로 종료한 다음 시스템 설정을 확인하세요. macOS 설치 허용 및 네트워크 권한은 권한 설정 안내를 참고하세요. 설치 파일과 플랫폼별 안내는 다운로드 센터에서 확인할 수 있습니다. 이 장에서는 추가 구성 요소를 다운로드하지 않습니다.

5. FakeDNS 및 도메인 매핑

FakeDNS는 실제 DNS 결과 대신 가상 주소를 반환하고, 내부적으로 도메인과 가상 주소의 매핑을 저장합니다. 앱은 가상 주소로 연결을 시도하고, 트래픽 가로채기 구성 요소나 코어가 매핑을 통해 실제 도메인을 복원합니다. 핵심은 실제 연결에 사용할 주소를 제공하는 것이 아니라 도메인 정보를 유지해 라우팅과 후속 DNS 조회가 원활히 연동되도록 하는 것입니다. FakeDNS를 거친 조회의 연결이 해당 가로채기 경로를 우회하면 앱이 가상 주소로 직접 연결을 시도해 실패할 수 있습니다.

DNS 조회와 연결이 같은 매핑 경로를 거쳐야 합니다

사용 전에 현재 코어와 클라이언트가 DNS 응답, 주소 풀 가로채기, 도메인 복원을 모두 포함한 전체 기능을 지원하는지 확인하세요. 설정 필드를 저장할 수 있다는 이유만으로 기능이 연결된다고 판단하지 마세요. 아래는 이 구조를 지원하는 코어의 설정 일부로, 주소 풀과 DNS 서버의 관계를 보여 줍니다. 기존 설정에 통합해야 하며 진입점, 라우팅, 아웃바운드 설정도 함께 필요합니다. 예시의 주소 풀은 벤치마크 테스트용 주소 범위에 속하므로 일반적인 공용 네트워크 대상으로 접근하는 데 사용하지 마세요.

{
  "fakedns": [
    {
      "ipPool": "198.18.0.0/15",
      "poolSize": 65535
    }
  ],
  "dns": {
    "servers": ["fakedns"]
  }
}

ipPool은 할당할 가상 주소 범위를 지정하고 poolSize는 풀의 크기를 설정합니다. 주소 풀은 실제 네트워크와 다른 트래픽 가로채기 도구의 주소 범위에 맞춰야 합니다. 눈에 띄는 주소처럼 보인다는 이유만으로 현재 사용 중인 서브넷으로 임의 변경하지 마세요. 풀 크기도 클수록 좋은 것은 아니므로 코어 구현과 실제 용도에 맞춰 선택해야 합니다. 주소 풀을 바꾸면 앱 캐시에 남은 기존 주소가 자동으로 갱신되지 않으므로 다시 조회한 뒤 새 연결을 만들어야 합니다.

진입점에서 가상 주소만 전달하지 말고 도메인을 복원

FakeDNS 복원을 지원하는 진입점에서는 관련 스니핑 기능을 켜는 방식이 일반적입니다. 아래는 진입점 객체 내부에 넣는 일부 설정이며 전체 inbounds 배열을 대체하면 안 됩니다. fakedns는 매핑에서 도메인 복원을 시도하고, HTTP 및 TLS 스니핑은 일부 애플리케이션 계층 정보를 추가로 식별합니다. 이 값을 허용하는지, 진입점에 추가 설정이 필요한지는 현재 코어의 실제 지원 여부를 확인하세요. GUI에서 생성하는 설정은 다른 방식으로 구현될 수도 있습니다.

{
  "sniffing": {
    "enabled": true,
    "destOverride": ["http", "tls", "fakedns"]
  }
}

일부 설정에는 스니핑 결과를 라우팅 판단에만 사용하고 실제 연결 대상을 변경하지 않는 routeOnly 옵션도 있습니다. 이 옵션을 FakeDNS에 무조건 적용해서는 안 됩니다. 최종 대상이 여전히 가상 주소라면 실제 도메인으로 연결할 수 없습니다. 라우팅 전용 스니핑 정책을 검토하기 전에 도메인 복원과 대상 처리부터 완료되었는지 확인하세요. 서로 다른 문서의 스니핑 옵션을 조합하면 클라이언트 기본 설정을 유지하는 것보다 문제를 추적하기 어려운 경우가 많습니다.

캐시 잔존과 우회 조회 확인

FakeDNS를 끈 뒤에도 앱이 캐시된 가상 주소를 계속 사용할 수 있습니다. 해당 앱의 기존 연결을 닫고 필요한 DNS 캐시를 비운 다음 다시 테스트하세요. 코어만 재시작해도 브라우저나 시스템의 캐시가 삭제되지 않을 수 있습니다. 반대로 FakeDNS를 켠 뒤 앱이 이전 실제 주소를 계속 사용한다고 해서 곧바로 FakeDNS가 작동하지 않는다고 판단해서도 안 됩니다. 대상 DNS 경로를 확실히 거치는 새 조회를 요청한 뒤 반환된 주소와 후속 도메인 복원 로그를 확인하세요.

앱 내장 DNS, 고정 IP 연결, 로컬 네트워크 이름은 예외 상황을 만들 수 있습니다. 고정 IP에는 복원할 도메인이 없고, 내부 도메인은 해당 이름에 응답할 수 있는 실제 DNS 서버가 필요합니다. 먼저 제어 가능한 테스트 범위에만 FakeDNS를 적용하고 웹, 로컬 네트워크, 필수 앱이 정상인지 확인한 뒤 사용 범위를 넓히세요. 켠 뒤에만 문제가 생기면 주소 풀을 확장하거나 폴백 DNS 서버를 여러 개 추가하기보다 일반 DNS와 기존 가로채기 방식으로 우선 복구하고 로그를 비교하세요.

6. 다중 구독 관리와 업데이트 범위

다중 구독 관리의 목적은 모든 항목을 알아보기 힘든 하나의 목록으로 합치는 것이 아니라 출처, 업데이트, 사용 관계를 추적할 수 있게 하는 것입니다. 구독마다 별도의 설명, 업데이트 정책, 용도를 기록하고 테스트용 출처와 일상용 출처를 분리하세요. 구독이 앱의 모든 설정을 관리한다고 가정해서는 안 됩니다. 가져오기 전에 내용이 서버 목록인지, 라우팅과 DNS를 포함한 전체 설정인지 확인해 일반적인 서버 업데이트로 더 큰 범위의 변경이 적용되지 않도록 하세요.

출처에서 다운로드하는 단계와 설정 적용 단계 구분

업데이트는 원격 콘텐츠 가져오기, 클라이언트 항목으로 파싱하기, 선택한 항목을 현재 연결에 적용하기의 세 단계로 나눌 수 있습니다. 한 단계가 성공했다고 나머지 단계도 완료된 것은 아닙니다. 업데이트 완료가 표시되면 항목 변경과 현재 선택 상태를 확인하고 새 연결을 만들어 보세요. 설정이 새로 적용되었더라도 기존 세션이 유지될 수 있으므로 열려 있는 이전 웹 페이지로 전환 결과를 판단할 수 없습니다. 새 연결의 실제 출구와 실행 로그를 확인하세요.

구독 업데이트에 사용하는 네트워크 경로도 별도로 확인해야 합니다. 현재 프록시를 통해 구독을 가져오면 직접 연결할 수 없는 문제를 해결할 수 있지만, 구독이 현재 작동하지 않는 서버를 복구하는 데 필요하다면 “업데이트하려면 실패한 연결이 필요함”이라는 문제가 생깁니다. 사용할 수 있는 업데이트 경로나 독립적인 예비 설정을 유지하고 어떤 출처가 프록시를 거쳐야 하는지 명확히 하세요. 의미를 모른 채 업데이트 프록시 옵션을 반복해서 바꾸지 말고, 연결, 인증, 인증서, DNS 중 어느 단계에서 오류가 발생하는지 먼저 확인하세요.

자동 업데이트의 불확실성 줄이기

안정적인 출처라면 자동 업데이트가 유용하지만, 처음부터 자주 업데이트하도록 설정하지 말고 결과를 확인할 수 있는 시간대를 선택하세요. 먼저 수동 업데이트를 여러 번 수행해 출처 형식이 안정적인지, 선택 항목이 유지되는지 확인한 뒤 자동 업데이트를 켜세요. 구독에 만료 시점이 있는 접근 정보가 포함될 수도 있으므로 주소가 만료될 가능성도 살펴보세요. 재시도를 반복해도 권한 문제는 해결되지 않으며 로그에 같은 오류가 쌓여 최초 원인을 찾기 어려워질 수 있습니다.

클라이언트에서 업데이트 시 기존 항목을 유지하거나 사용할 수 없는 항목을 삭제하도록 선택할 수 있다면 두 방식의 장단점을 이해하세요. 기존 항목을 유지하면 임시로 되돌아가기 쉽지만 사용할 수 없는 설정이 목록에 쌓일 수 있습니다. 삭제하면 출처와 목록을 일치시킬 수 있지만 현재 사용 중인 항목이 즉시 사라질 수 있습니다. 정리 방식을 결정하기 전에 별도 백업이 있는지 확인하세요. 수동으로 임시 수정한 서버 설정은 다음 구독 업데이트 후에도 유지된다고 가정해서는 안 됩니다. 필요하면 명확한 표시를 붙인 별도 설정으로 복사해 두세요.

병합, 중복 제거, 출처 신뢰도

중복을 제거할 때는 설명만 비교하지 말고 실제 연결 매개변수를 비교해야 합니다. 서버 주소가 같아도 포트, 전송 경로, 보안 설정이 다를 수 있으므로 바로 병합하지 마세요. 이름이 달라도 같은 연결을 중복으로 표현한 것일 수 있습니다. 먼저 단일 출처 안에서 정리한 뒤 출처 간 중복을 확인하고 출처 정보는 유지하세요. 클라이언트의 자동 중복 제거 방식이 어떤 필드를 비교하는지 설명하지 않는다면 테스트 그룹에서 먼저 사용해 결과를 확인하세요. 일상 설정 전체에 되돌릴 수 없는 정리를 바로 적용하지 마세요.

출처에 원격 리소스 주소나 익숙하지 않은 확장 필드가 포함될 수도 있습니다. 필요한 항목만 가져오고 시스템 설정 전체 덮어쓰기, 라우팅 전체 변경, 추가 권한 요청이 있다면 용도를 먼저 확인하세요. 구독 주소에는 접근 자격 정보가 포함될 수 있으므로 알 수 없는 온라인 변환 서비스에 입력하지 마세요. 변환 과정에서 설정의 의미가 달라질 수도 있습니다. 형식이 호환되지 않으면 제공자가 지원하는 클라이언트 형식을 먼저 확인한 뒤 로컬에서 검토할 수 있는 방법을 고려하세요.

기기를 옮길 때는 관계를 보존하고 실행 상태 전체를 복사하지 마세요

기기를 바꿀 때는 그룹 이름, 구독 용도, 필요한 규칙, 수동 설정을 기록한 뒤 클라이언트가 지원하는 내보내기 및 가져오기 기능을 사용하세요. 데스크톱의 경로, 포트, 네트워크 권한 설정을 Android에 그대로 적용해서는 안 됩니다. 기기별 TUN 설정도 다시 확인해야 합니다. 가져온 뒤에는 출처별로 업데이트하고 기본 연결을 먼저 복구한 다음 고급 규칙을 추가하세요. 이렇게 하면 여러 변경이 한꺼번에 섞인 문제 상황에 빠지지 않고 출처 문제와 플랫폼 차이를 구분할 수 있습니다.

7. 사용자 지정 아웃바운드와 태그 참조

아웃바운드는 연결이 코어를 벗어날 때 사용할 처리 방식을 정의하고, 라우팅은 태그로 해당 항목을 참조합니다. 프록시, 직접 연결, 차단은 고정된 세 개의 버튼이 아니라 서로 연결된 설정 객체입니다. 사용자 지정 설정을 시작하기 전에 클라이언트에서 전체 설정, 일부 아웃바운드, GUI 라우팅 필드 중 무엇을 편집하는지 확인하세요. 각각 병합 방식이 다릅니다. 실행 중인 임시 파일을 직접 수정하면 서버를 바꾸거나 재시작할 때 덮어쓰일 수 있으므로 안정적인 설정 관리 방법으로 사용할 수 없습니다.

추적할 수 있는 태그 관계부터 구성

참조할 각 아웃바운드에는 알아보기 쉽고 고유한 tag를 지정해야 하며 라우팅의 outboundTag는 태그와 정확히 일치해야 합니다. 대소문자, 공백, 철자가 다르면 참조가 실패할 수 있습니다. 아래 예시는 기본 아웃바운드 객체 두 개를 모두 보여 주지만 클라이언트의 아웃바운드 배열 전체를 교체하라는 뜻은 아닙니다. 통째로 교체하면 기존 프록시 아웃바운드도 사라집니다. 기존 설정에 같은 이름의 객체가 있는지 확인해 중복 정의를 피하세요.

{
  "outbounds": [
    {
      "tag": "direct",
      "protocol": "freedom",
      "settings": {}
    },
    {
      "tag": "block",
      "protocol": "blackhole",
      "settings": {}
    }
  ]
}

freedom은 이 기기의 네트워크를 통해 대상에 직접 연결하고, blackhole은 매칭된 연결을 버립니다. 직접 연결이라고 해서 대상에 반드시 접근할 수 있는 것은 아닙니다. 로컬 DNS, 주소 체계, 게이트웨이, 방화벽의 영향을 받습니다. 차단 동작도 항상 같은 오류로 표시되는 것은 아니며 앱에서 연결 실패를 표시하거나 자체적으로 재시도할 수 있습니다. 테스트할 때는 웹 페이지의 메시지만 보고 규칙이 적용되었는지 판단하지 말고 실제 출구 로그를 함께 확인하세요.

기본 출구와 명시적 라우팅을 함께 확인

라우팅 규칙에 매칭되지 않으면 일반적인 코어 설정에서는 보통 첫 번째 아웃바운드를 사용하며, 클라이언트가 기본 규칙을 생성할 수도 있습니다. 따라서 아웃바운드 순서를 바꾸는 것은 단순한 목록 정리가 아니라 동작을 바꾸는 일입니다. 위 예시를 단독으로 사용하면 첫 번째 항목은 직접 연결이며 “기본 프록시”가 아닙니다. 기본 출구로 프록시를 사용하려면 기존 프록시 객체의 위치나 클라이언트가 생성한 최종 규칙을 확인하세요. 화면에서 서버를 선택했다는 이유로 전체 설정의 실제 순서를 간과하지 마세요.

특정 업무 연결에 별도 출구를 사용하려면 먼저 최종 설정에 해당 객체가 실제로 존재하는지 확인한 뒤 가장 구체적인 라우팅 조건을 추가하세요. 구독 그룹의 여러 서버가 모두 자동으로 참조 가능한 아웃바운드가 되는 것은 아닙니다. 현재 선택된 서버도 고정 태그를 사용할 수 있습니다. 여러 출구를 함께 사용하려면 클라이언트가 해당 설정 생성을 지원하거나 완전하게 실행 가능한 사용자 지정 설정을 관리해야 합니다. 서버 설명을 태그로 입력하는 것만으로 아웃바운드가 생기지는 않습니다.

프록시 체인에는 명확한 다이얼링 관계가 필요합니다

다단계 포워딩과 여러 출구 중 하나를 선택하는 것은 서로 다른 기능입니다. 여러 출구 선택은 연결별로 다른 경로를 사용하고, 프록시 체인은 하나의 연결이 여러 처리 단계를 차례로 거치도록 합니다. 체인 다이얼링을 설정하기 전에 현재 코어가 해당 필드를 지원하는지, 각 서버에 접근할 수 있는지, 루프가 발생하지 않는지 확인하세요. 어떤 코어에서 사용하는 다이얼링 필드인지 확인하지 않은 채 다른 코어 설정에 그대로 복사하지 마세요. 각 출구를 따로 검증한 뒤 체인으로 구성해야 어느 구간에서 문제가 생겼는지 찾을 수 있습니다.

아웃바운드에 인터페이스나 소스 주소를 지정할 때는 네트워크가 바뀌는 상황도 고려해야 합니다. 무선 인터페이스를 고정하면 유선 연결로 전환했을 때 동작하지 않을 수 있고, 소스 주소를 고정하면 주소를 다시 할당받은 뒤 더 이상 이 기기에 속하지 않을 수 있습니다. 이런 필드는 네트워크 조건이 명확한 환경에 적합하며, 연결 실패를 해결하는 범용 방법이 아닙니다. 일반적인 직접 연결만 필요하다면 시스템 라우팅을 유지하는 편이 관리하기 쉽습니다. 다중 네트워크 인터페이스가 꼭 필요하다면 인터페이스 변경 시 확인할 항목과 복구 방법을 기록하세요.

생성된 설정을 확인한 뒤 장기 설정으로 저장

사용자 지정 설정을 저장한 다음 클라이언트가 제공하는 설정 검사 기능을 실행하고 실제 시작 로그를 확인하세요. 태그가 고유한지, 참조 대상이 존재하는지, 기본 출구가 올바른지, 사용자 지정 객체가 병합되거나 덮어써졌는지 살펴보세요. 화면 설정과 실행 결과가 다르면 실제 적용된 설정을 기준으로 문제를 해결해야 합니다. 생태계와 코어의 차이는 Project V, V2Fly, Xray의 관계 안내를 참고하세요. 지원되는 설정 범위를 확인한 뒤 코어를 바꿀지 결정하세요.

8. 검증, 로그 및 설정 복구

고급 설정에는 반복 가능한 검증 절차가 필요합니다. 한 번에 하나의 명확한 문제만 해결하고 변경 전에 예상 결과를 적어 두세요. 예를 들면 “특정 업무 도메인이 지정된 아웃바운드를 사용한다”, “로컬 네트워크 주소는 계속 직접 연결된다”와 같습니다. 구독 업데이트, 코어 전환, TUN 활성화, DNS 변경을 동시에 한 뒤 웹 페이지 한 번 열어 성공 여부를 판단하지 마세요. 변경 범위가 클수록 원인을 찾기 어렵고 결국 전부 되돌리게 되어 유용한 테스트 결과를 잃을 수 있습니다.

최소 테스트 항목 구성

최소 네 가지 항목을 준비하세요. 일반 도메인 접속, 직접 연결이 확실한 대상, 프록시가 필요한 업무 연결, 로컬 네트워크 리소스입니다. 각 항목에서 안정적으로 접근할 수 있는 대상을 고르고 예상 진입점과 출구를 기록하세요. UDP, 듀얼 스택, 특정 앱을 사용한다면 해당 테스트도 추가합니다. 이전 세션을 재사용할 수 있는 페이지를 반복해서 새로고침하기보다 새 연결을 만들어 테스트하세요. 앱 연결 풀과 브라우저 캐시 때문에 설정을 바꿔도 달라진 점이 없는 것처럼 보일 수 있습니다.

연결 단계에 따라 로그 확인

먼저 코어가 정상적으로 시작되었는지 확인하세요. 시작이 완료되지 않았다면 원격 연결을 테스트할 필요가 없습니다. 다음으로 로컬 진입점에서 연결을 받았는지 확인한 뒤 대상 도메인이나 주소, 규칙 선택, 아웃바운드 오류를 살펴보세요. 포트 사용 중 오류는 로컬 리스닝 단계, DNS 조회 실패는 DNS 단계에서 확인해야 합니다. 연결 시간 초과는 원격 대상에 접근할 수 없는 문제일 수 있고, 인증서 오류는 보통 보안 핸드셰이크 단계에서 발생합니다. 모든 문제를 “서버 바꾸기” 하나로 해결하려 해서는 안 됩니다.

문제 해결에 필요한 수준으로만 로그를 자세히 기록하고, 확인이 끝나면 평소 수준으로 되돌리세요. 지나치게 상세한 로그를 계속 켜 두지 마세요. 로그를 공유할 때는 구독 주소, 사용자 식별 정보, 인증 필드, 불필요한 내부 도메인을 숨기고 오류 전후에 필요한 행만 남기세요. 테스트 시각도 중요합니다. 수동 테스트와 관련된 로그가 어느 부분인지 명확히 해 백그라운드 앱 요청을 대상 요청으로 착각하지 않도록 하세요. 자주 발생하는 오류를 더 자세히 살펴보려면 실행 로그 읽는 방법을 참고하세요.

가장 최근 변경부터 되돌리기

복구할 때는 가장 최근 변경 하나를 되돌린 뒤 기준 설정을 다시 테스트하세요. FakeDNS를 도입한 뒤 문제가 생겼다면 일반 DNS로 되돌린 다음 기존 매핑 결과도 비워야 합니다. TUN이 원인이라면 가로채기를 끈 뒤 시스템 경로와 DNS를 확인하세요. 사용자 지정 아웃바운드가 원인이라면 태그와 기본 출구 순서를 복구하세요. 화면에서 스위치 하나를 끄는 것만으로 파생된 상태가 모두 되돌려졌다고 볼 수는 없습니다. 캐시 때문에 잘못 판단하지 않도록 복구 단계마다 새 연결을 확인하세요.

검증이 완료된 설정과 필요한 설명을 한 부씩 장기 보관하세요. 설명에는 클라이언트, 실제 코어, 진입 방식, 필요한 규칙 리소스, 특별 권한을 적습니다. 백업에 모든 임시 로그를 포함할 필요는 없지만 주요 설정 관계를 복원할 수 있어야 합니다. 소프트웨어를 업데이트한 뒤에는 기본 연결부터 확인하고 사용자 지정 설정을 살펴보세요. 시작 중 앱이 종료된다면 시작 중 강제 종료 및 폴더 권한 문제 해결을 참고하세요. 앱 시작 문제를 라우팅 오류로 오해하지 마세요.

정상 동작한 설정을 참고 자료로 정리

검증을 마쳤다면 기본값이 아닌 설정마다 이유를 한 문장으로 적으세요. 예를 들어 “이 도메인은 내부 DNS를 유지해야 함”, “이 업무 연결은 별도 출구 사용”과 같습니다. 필드 값만 옮겨 적지 말고 필요한 이유를 기록해야 환경이 바뀌었을 때 설정이 여전히 필요한지 판단할 수 있습니다. 구독 업데이트, 네트워크 전환, 코어 전환 후에는 직접 영향을 받는 항목을 다시 확인하세요. 영향을 받지 않은 부분까지 전부 재검증할 필요는 없습니다. 그래야 관리 범위를 통제할 수 있습니다.

문제를 찾지 못했다면 연결 하나, 규칙 묶음 하나, 출구 하나로 범위를 좁히고 민감 정보를 제거한 설정 일부와 관련 로그를 준비한 뒤 문제 해결을 참고하세요. 기본 설정 절차를 다시 진행하려면 입문 가이드로 돌아가세요. 설치 플랫폼이나 기기 아키텍처를 바꾸려면 다운로드 센터를 확인하세요. 이 가이드의 목표는 모든 설정 변경에 근거와 검증 절차, 명확한 복구 방법을 갖추는 것입니다.