V2Ray 고급 설정
구독·라우팅·DNS

설정 계층과 기본 상태로 되돌리기

클라이언트, 코어, 시스템을 구분하세요

접속 성공 여부는 서버 설정만으로 결정되지 않습니다. 그래픽 클라이언트는 구독, 현재 서버, UI 옵션을 저장한 뒤 코어가 읽을 수 있는 설정을 생성합니다. 코어는 인바운드 수신, 라우팅 규칙 매칭, 도메인 조회, 아웃바운드 연결을 담당하고, 운영체제는 앱 트래픽이 클라이언트로 들어갈지 결정합니다. 문제를 진단할 때는 먼저 어느 계층에서 오류가 발생했는지 확인해야 합니다. 예를 들어 브라우저가 시스템 프록시를 따르지 않는 것은 트래픽 진입점 문제이고, 코어에서 아웃바운드 태그를 찾을 수 없다는 오류는 설정 참조 문제입니다. 두 문제를 같은 스위치로 해결할 수는 없습니다.

v2rayN의 ‘매개변수 설정’, ‘라우팅 설정’, 메인 창의 시스템 프록시 옵션은 각각 다른 단계에 영향을 줍니다. ‘시스템 프록시 자동 설정’은 일반적으로 앱이 사용하는 시스템 프록시 진입점만 바꾸며, 가상 네트워크 어댑터를 활성화하는 기능은 아닙니다. ‘Tun 사용’을 활성화하면 별도의 트래픽 처리 경로가 추가됩니다. Android의 v2rayNG는 시스템 VPN 인터페이스로 트래픽을 전달하고, ‘라우팅 설정’은 코어에 들어온 트래픽을 분기합니다. UI의 ‘중국 본토 우회’는 서로 다른 규칙 템플릿을 가리킬 수 있으므로, 이름이 같다고 최종 생성 설정도 같다고 단정해서는 안 됩니다.

반복 검증할 수 있는 기본 상태를 만드세요

시작하기 전에 현재 정상 작동하는 설정을 보존하세요. 클라이언트 이름, 선택한 코어, 현재 서버, 라우팅 모드, 시스템 프록시 상태, DNS 관련 옵션을 기록합니다. 클라이언트의 백업 또는 내보내기 기능으로 설정을 저장할 때는 구독 주소, 연결 식별자, 인증 정보가 파일에 포함될 수 있으므로 안전한 폴더에 보관하세요. 도움을 요청하기 위해 화면을 캡처한다면 먼저 민감한 내용을 가리세요. 인증 정보가 포함된 전체 설정을 공개 게시판에 올리지 말고, 오류가 발생하기 전의 작업 맥락을 빼고 마지막 오류 한 줄만 캡처하지도 마세요.

기본 상태를 검증할 때는 대표적인 동작 세 가지를 시험하는 것이 좋습니다. 프록시를 명시적으로 사용하는 앱으로 일반 웹페이지를 열고, LAN에 있는 자체 서비스에 접속한 다음, 평소 사용하는 업무 앱을 테스트하세요. 기록할 내용은 성공·실패 여부, 오류 유형과 발생 조건이지 단일 지연 시간 수치가 아닙니다. 브라우저에서 웹페이지가 열린다고 해서 다른 앱의 트래픽까지 처리된다는 뜻은 아닙니다. LAN 접속이 정상이어도 DNS 조회가 의도한 경로를 거친다는 보장은 없습니다. 설정 변경 전후에 같은 동작을 반복해야 결과를 비교할 수 있습니다.

한 번에 변수 하나만 바꾸세요

구독 구성, 라우팅, DNS 순으로 조정하고 TUN과 FakeDNS는 마지막에 활성화하는 것이 좋습니다. 각 항목을 변경할 때마다 다시 연결하고 기본 테스트를 반복하세요. 클라이언트에서 코어를 재시작하라고 하면 설정 창만 닫힌 것이 아니라 새 시작 과정이 로그에 기록됐는지 확인하세요. 코어를 바꾸기 전에는 프로토콜과 보안 매개변수의 지원 범위를 확인하세요. 특히 REALITY 설정은 주의해야 합니다. 자세한 차이는 Xray와 V2Fly 코어 비교를 참고하세요. 이름이 비슷하다고 호환되는 것은 아닙니다.

문제가 발생하면 설정을 바꾼 순서의 역순으로 되돌리세요. 새로 추가한 트래픽 처리나 이름 조회 기능을 먼저 끄고, 라우팅 템플릿을 복원한 다음, 기존 서버 설정을 복구합니다. 되돌린 뒤에도 문제가 계속되면 시스템 프록시 잔여 설정, 네트워크 전환, 다른 VPN을 확인하세요. 클라이언트를 업데이트하기 전에는 설치 파일 페이지에서 플랫폼에 맞는 파일을 선택할 수 있습니다. 단, 같은 문제를 진단하는 동안 클라이언트, 코어, 구독을 동시에 바꾸지 마세요. 원인과 결과를 파악하기 어려워지고 재현 가능한 오류도 우연한 문제처럼 보일 수 있습니다.

구독 그룹과 서버 필터링

그룹은 출처를 먼저, 용도를 다음으로 구분하세요

구독 그룹의 가장 중요한 역할은 출처를 분리해 관리하는 것입니다. v2rayN에서 ‘구독 그룹’을 열고 그룹 관리로 이동해 구독 주소마다 별도 항목을 만드세요. 알아보기 쉬운 메모를 적되 비밀번호나 전체 링크는 쓰지 마세요. 메모에는 출처나 용도를 기록하는 것이 좋습니다. 같은 출처의 구독에 서로 다른 필터 조건을 적용해야 한다면 그룹을 나눌 수 있지만, 업데이트 후 구분하기 어려운 중복 항목이 생기지 않는지 확인하세요. 수동으로 가져온 연결도 별도 그룹에 두면 구독 업데이트로 다시 생성된 서버와 섞이지 않습니다.

v2rayNG에서는 보통 사이드 메뉴의 ‘구독 그룹 설정’에서 주소를 관리한 뒤, 메인 화면으로 돌아와 구독을 업데이트합니다. v2flyNG의 메뉴와 지원 필드는 실제 UI를 기준으로 확인하세요. 구독 주소를 저장했다고 서버 목록에 내려받아진 것은 아니며, 업데이트에 성공했다고 사용할 서버가 선택된 것도 아닙니다. 작업 후에는 현재 그룹, 목록 내용, 현재 활성 항목을 확인하세요. 업데이트 후 목록이 비어 있다면 원격에서 내용이 반환되지 않은 것인지, 형식을 파싱하지 못한 것인지, 클라이언트의 필터링 단계에서 모든 항목이 제외된 것인지 먼저 구분하세요.

필터링은 목록을 정리하는 기능이지 접근 제어가 아닙니다

서버 필터링은 보통 메모 텍스트, 프로토콜 유형 또는 클라이언트가 제공하는 조건으로 항목을 남깁니다. 이는 가져오기 또는 표시 결과를 바꾸는 기능이며, 앱이 접근할 수 있는 대상을 제한하거나 트래픽 분기 정책을 자동으로 만들지는 않습니다. 서버 이름에 특정 지역명이 들어 있어도 실제 접속 출구나 기능이 그 지역에 해당한다고 볼 수 없습니다. 필터링은 목록을 정돈하는 데 유용하지만 보안 경계로 사용해서는 안 됩니다. 처음 설정할 때는 필터를 끈 상태로 전체 구독을 정상적으로 파싱하는지 확인한 뒤, 쉽게 검증할 수 있는 조건을 하나 추가해 결과를 살펴보세요.

클라이언트마다 필터 필드가 일반 키워드, 정규식, 포함·제외 규칙 등 서로 다른 방식을 지원할 수 있습니다. 먼저 필드 옆 안내를 읽고, 일반 텍스트만 받는 입력란에 정규식을 넣지 마세요. 정규식을 지원한다고 명시된 경우 세로줄은 ‘또는’를 뜻하고, 괄호는 그룹을 지정하며, 점은 기본적으로 임의의 문자와 일치합니다. 점 자체를 찾으려면 이스케이프해야 합니다. 대소문자 구분 여부와 포함·제외 규칙의 적용 순서는 현재 클라이언트에서 확인하세요. 다른 앱의 동작을 그대로 적용하지 마세요.

(?i)(테스트|예비)

위 예시는 해당 정규식 문법을 지원하는 필드에서만 사용할 수 있으며, 대소문자를 구분하지 않고 ‘테스트’ 또는 ‘예비’와 일치합니다. 이 표현식 자체에는 항목을 남기거나 삭제하는 의미가 없으며, 포함 조건과 제외 조건 중 어느 위치에 입력했는지에 따라 달라집니다. 테스트 그룹에서 먼저 확인하고, 유일하게 사용할 수 있는 운영 그룹에 바로 적용하지 마세요. 서버 메모는 구독 제공자가 정하므로 나중에 바뀔 수 있고, 메모에 의존하는 필터 결과도 함께 바뀝니다. 중요한 항목이 사라지면 곧바로 새 구독을 구매하거나 출처를 바꾸기보다 조건을 잠시 지우고 다시 업데이트하세요.

업데이트 경로와 서비스 트래픽 경로를 구분하세요

구독 업데이트도 네트워크 요청입니다. 클라이언트에서 ‘프록시를 통해 업데이트’와 일반 업데이트를 모두 제공한다면 구독 주소에 도달할 수 있는 경로를 선택하세요. 현재 프록시가 작동하지 않는데 그 프록시로 수정된 목록을 가져오려 하면 의존성 문제가 생길 수 있습니다. 반대로 구독 주소가 현재 연결을 통해서만 열리는 경우 직접 업데이트가 실패할 수 있습니다. 문제를 진단할 때는 업데이트 요청과 서비스 연결을 각각 확인하세요. 웹페이지가 열린다고 구독 API도 반드시 작동하는 것은 아닙니다.

업데이트가 끝나면 활성 서버가 여전히 원래 구독에 속하는지 확인하세요. 일부 업데이트는 항목을 새로 만들기 때문에 이전 선택 기록이 새 목록의 항목과 일치하지 않을 수 있습니다. 프로토콜 필드, 전송 방식, 보안 옵션이 유지됐는지 확인한 뒤 활성 항목으로 설정하세요. 클라이언트가 특정 연결 형식을 지원하지 않는다고 알리면 파일 확장자를 바꾸거나 일부 필드만 남겨 강제로 가져오지 마세요. 선택한 클라이언트와 코어가 해당 형식을 지원하는지 확인한 뒤 구독 제공자에게 출력 형식을 문의하세요.

목록이 비어 있거나 가져오기 형식 오류, 업데이트 중 네트워크 오류가 발생하면 구독 파싱 실패 점검 목록을 따라 원인을 하나씩 확인하세요. 먼저 필터링을 끄고 출처와 업데이트 경로를 확인한 다음 인코딩과 응답 내용을 살펴보세요. 그룹 관리는 설정 출처를 추적하기 위한 기능입니다. 연결 품질과 프로토콜 호환성은 서버를 선택한 뒤 별도로 검증해야 합니다.

라우팅 규칙 활용

규칙 수보다 우선순위가 중요합니다

라우팅은 코어가 받은 연결 정보를 입력으로 사용하고, 선택된 아웃바운드를 출력으로 반환합니다. v2rayN의 ‘라우팅 설정’에서 현재 설정을 확인하고, 메인 화면에서 해당 설정이 선택되어 있는지 먼저 확인한 뒤 규칙을 편집하세요. Xray와 V2Fly의 일반적인 라우팅 동작은 규칙을 순서대로 확인해 처음 일치하는 규칙을 적용하는 것입니다. 한 규칙 안에서 서로 다른 필드는 보통 모두 조건을 충족해야 하지만, 도메인 목록이나 IP 목록 안에서는 항목 중 하나와 일치하면 됩니다. 도메인과 포트를 한 규칙에 함께 지정하면 둘 중 하나가 아니라 둘 다 충족해야 합니다.

일반적으로 필요한 LAN 직접 연결 규칙, 업무 전용 규칙, 범용 분류 규칙 순으로 배치하고, 끝에서 기본 아웃바운드가 어떤 규칙에도 일치하지 않은 트래픽을 처리하도록 합니다. 범위가 지나치게 넓은 규칙을 앞에 두면 뒤의 세부 조건이 적용될 기회가 없습니다. ‘중국 본토 우회’ 같은 기본 설정은 시작점으로 활용할 수 있지만, 어떤 도메인 목록과 IP 목록, 이름 조회 정책이 포함되는지는 현재 설정이나 생성 결과를 확인하세요. UI에 표시되는 이름은 설정에 들어가는 메뉴일 뿐 전체 규칙 설명이 아닙니다.

도메인 규칙과 IP 규칙의 적용 범위

full:은 도메인 전체와 일치시키고, domain:은 해당 도메인과 하위 도메인에 적용합니다. geosite:은 도메인 분류 리소스를 참조하고, geoip:는 IP 분류 리소스를 참조합니다. 아래 예시는 도메인과 사설 주소를 직접 연결하는 방법을 보여줍니다. 전체 설정에 direct라는 아웃바운드가 있어야 합니다. 클라이언트의 규칙 편집기를 사용할 때는 조건을 해당 필드에 입력하세요. 라우팅 객체 전체를 도메인 입력란 하나에 붙여 넣으면 안 됩니다.

{
  "routing": {
    "domainStrategy": "IPIfNonMatch",
    "rules": [
      {
        "type": "field",
        "domain": ["full:example.com", "domain:example.org"],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "ip": ["geoip:private"],
        "outboundTag": "direct"
      }
    ]
  }
}

예시 도메인은 매칭 문법을 설명하기 위한 것이므로 실제로 관리할 도메인으로 바꿔야 합니다. IP 규칙이 도메인 규칙을 자동으로 포괄하지는 않습니다. 도메인은 여러 주소로 조회될 수 있고 네트워크에 따라 다른 결과를 반환할 수 있습니다. 반대로 도메인 규칙만으로는 IP 주소에 직접 접속하는 앱을 처리하지 못할 수 있습니다. LAN 서비스는 접속 방식, DNS가 반환하는 주소, 가상 네트워크 어댑터의 라우팅을 함께 고려해야 합니다. 일부 서비스 이름은 로컬 검색 프로토콜에 의존하므로 도메인 규칙 하나만 추가해도 해결되지 않습니다.

라우팅 이름 조회 정책과 DNS 아웃바운드 정책은 다릅니다

AsIs는 가능한 한 기존 대상 정보를 이용해 매칭하고, IPIfNonMatch는 도메인 규칙에 일치하지 않을 때 주소를 조회한 뒤 IP 조건을 다시 확인합니다. IPOnDemand는 IP 정보가 필요한 규칙을 확인할 때 주소 조회를 수행할 수 있습니다. 이 설정은 라우팅 단계에서 주소 정보가 필요한 시점을 결정하며, DNS 요청이 어떤 아웃바운드를 거치는지를 직접 지정하지는 않습니다. 이름 조회 정책과 DNS 서버를 동시에 바꾸면 문제의 원인을 구분하기 어려워집니다. 먼저 조회 서비스를 고정한 뒤 정책 변경에 따른 규칙 매칭 차이를 비교하세요.

스니핑은 지원되는 트래픽에서 도메인 정보를 파악하는 데 도움이 될 수 있지만 모든 프로토콜을 안정적으로 식별하지는 못합니다. 암호화된 캡슐화, 앱의 IP 직접 사용, 연결 재사용, 메타데이터 부족 등이 식별에 영향을 줄 수 있습니다. 스니핑을 활성화한 뒤에는 대상 주소가 재작성되는지도 확인하세요. 라우팅 정보만 보완하려는 경우 현재 코어에 라우팅 전용 옵션이 있는지 살펴보세요. 스니핑이 도메인 규칙 매칭을 보장하지 않으며, 모든 DNS 설정 누락을 대신 해결해 주는 것도 아닙니다.

로그에서 실제 규칙 매칭을 확인하세요

규칙을 저장한 뒤 코어를 다시 불러오고 새 연결을 시작해 로그에 표시된 아웃바운드 태그를 확인하세요. 기존 장기 연결은 이전 경로를 계속 사용할 수 있으며, 브라우저 캐시와 백그라운드 연결도 확인을 방해할 수 있습니다. 필요한 경우 테스트 앱을 종료한 뒤 다시 실행하세요. 규칙이 적용되지 않으면 먼저 활성 설정을 확인하고, 앞에 놓인 규칙을 살펴본 다음, 코어가 도메인과 IP 중 무엇을 받았는지 확인하세요. 마지막으로 분류 리소스가 있는지 확인합니다. 리소스 파일이 없으면 보통 시작 단계에서 오류가 발생하므로 반복해서 다시 연결하는 것으로 해결하려 하지 마세요.

기본 동작도 명확하게 확인해야 합니다. 이 계열의 코어에서는 어떤 규칙에도 일치하지 않는 연결이 전체 설정의 첫 번째 아웃바운드로 전달되는 경우가 많습니다. 그래픽 클라이언트가 이를 기준으로 기본 프록시 또는 직접 연결을 지정할 수도 있습니다. 규칙 목록만 보고 기본 경로를 추측하지 마세요. 동작을 고정하려면 클라이언트의 기본 규칙 설정을 사용하거나 사용자 지정 설정에 마지막 매칭 규칙을 명시하고, 관리 트래픽에 별도 요구 사항이 있는지도 확인하세요. 용어는 용어집에서, 일반적인 연결 문제는 문제 해결에서 확인할 수 있습니다.

DNS 설정 최적화

서비스 연결과 DNS 조회 경로를 각각 파악하세요

DNS를 설정할 때는 세 가지를 먼저 확인해야 합니다. 누가 조회를 시작하는지, 누가 결과를 반환하는지, 조회 요청이 어떤 네트워크 경로를 거쳐 DNS 서버에 도달하는지입니다. 앱은 시스템 DNS를 직접 사용할 수도 있고 자체 암호화 DNS를 사용할 수도 있습니다. 코어가 라우팅 매칭, 연결 대상, DNS 서버 주소를 위해 조회를 시작할 수도 있습니다. 따라서 클라이언트에 원격 DNS 주소를 입력해도 시스템의 모든 조회가 그 주소를 거치는 것은 아닙니다. 먼저 앱 트래픽이 클라이언트에 들어오는지 확인한 다음, 조회 요청을 코어가 처리하는지 살펴보세요.

v2rayN에서는 ‘매개변수 설정’에서 DNS 관련 항목을 찾을 수 있습니다. v2rayNG에서는 ‘설정’의 ‘로컬 DNS 사용’, 원격 DNS, 도메인 정책 등을 확인하세요. UI에서 말하는 ‘로컬’은 대개 클라이언트 측 DNS 처리 모듈을 뜻하며, 요청이 반드시 LAN으로만 전송된다는 의미는 아닙니다. 클라이언트마다 설정 생성 방식도 다릅니다. 옵션을 켠 뒤에는 로그나 생성된 설정을 확인해 사용 중인 서버와 정책을 살펴보세요. 스위치 색상만으로 설정이 완전히 적용됐다고 판단해서는 안 됩니다.

헷갈리기 쉬운 세 가지 정책 구분

아래는 커널 DNS 객체의 일부 예시로, IPv4 주소만 조회하고 DNS 서버를 지정하는 방법을 보여줍니다. DNS 트래픽의 라우팅 설정은 포함하지 않으며, 요청이 자동으로 프록시를 통과한다는 뜻도 아닙니다. 암호화 DNS를 설정할 때는 현재 코어에서 지원하는 주소 문법, 인증서 검증, 도메인 조회 경로도 확인해야 합니다. DNS 서버 주소 자체가 도메인이라면 최초 조회에 어떤 사용 가능한 DNS 서버가 필요한지 확인하세요. 연결하려면 먼저 도메인을 조회해야 하는데 조회에도 그 연결이 필요하다면 순환 의존이 발생합니다.

{
  "dns": {
    "queryStrategy": "UseIPv4",
    "servers": [
      "1.1.1.1"
    ]
  }
}

서비스 경계에 맞춰 조회 방식을 선택하세요

LAN 내부 도메인은 보통 라우터, 기업 DNS, 검색 도메인에 의존하므로 해당 로컬 조회 경로를 유지해야 합니다. 모든 조회를 공용 DNS 서버로 보내면 내부 서비스를 찾지 못할 수 있습니다. 외부 서비스는 조회 결과와 선택한 아웃바운드가 합리적으로 일치해야 합니다. 서비스가 지역별로 다른 주소를 제공하는데 DNS 조회가 실제 출구와 다른 네트워크에서 이뤄지면 적절하지 않은 주소를 받을 수 있습니다. 서버를 더 많이 추가하는 것보다 도메인 유형별 조회와 연결 경로를 이해하기 쉽게 설계하는 것이 중요합니다.

DNS 서버를 여러 개 설정한다고 목록 순서대로 하나씩 시도한다고 단정해서는 안 됩니다. 코어 구현에 따라 도메인 조건으로 병렬 조회를 하거나 결과를 합칠 수 있고, 대체 서버 필드의 지원 방식도 다릅니다. 안정적인 단일 조회 경로로 먼저 동작을 확인한 다음, 도메인별 서버를 추가하고 기본 대체 경로가 나머지 대상을 처리하는지 점검하세요. 외부 DNS 서버로 보낼 수 없는 내부 도메인은 목록 앞에 사설 주소를 추가하는 것만으로 끝내지 말고, 공용 대체 경로에서 명시적으로 제외하세요.

캐시, 듀얼 스택, 로그 점검 순서

DNS를 바꾼 뒤에도 앱, 시스템, 코어에 이전 결과가 남아 있을 수 있습니다. 테스트 앱을 종료한 뒤 다시 실행하고, 운영체제가 제공하는 방법으로 DNS 캐시를 새로 고침하세요. 필요한 경우 클라이언트 코어도 재시작합니다. 실패할 때마다 곧바로 DNS 서버를 바꾸면 캐시 때문에 결과를 비교하기 어려워집니다. 로그에 시간 초과가 나타나면 조회 경로에 접속할 수 있는지 먼저 확인하세요. 주소를 받았는데도 연결에 실패하면 대상 주소 유형, 라우팅, 원격 연결을 확인하고 DNS 옵션만 계속 바꾸지 마세요.

IPv6 문제는 ‘주소를 조회할 수 있는지’와 ‘연결을 완료할 수 있는지’를 구분해야 합니다. 네트워크가 IPv6 주소를 반환해도 안정적인 IPv6 출구나 올바른 가상 네트워크 어댑터 경로가 없을 수 있습니다. 주소 유형을 임시로 제한하면 원인을 찾는 데 도움이 되지만, 모든 환경에 적용할 고정 최적화로 간주해서는 안 됩니다. 반대로 IPv6가 필요한 네트워크에서 IPv4만 조회하면 접속이 불가능해질 수도 있습니다. 진단이 끝나면 현재 네트워크 기능에 맞는 정책으로 복원하고 새 연결로 검증하세요. 웹페이지 한 번의 로딩 속도로 전체 조회 설정을 판단하지 마세요.

TUN 모드

트래픽 처리 범위가 달라져도 규칙이 무효가 되는 것은 아닙니다

TUN은 가상 네트워크 어댑터와 시스템 라우팅을 통해 조건에 맞는 IP 트래픽을 클라이언트로 전달하므로 시스템 프록시를 따르지 않는 앱에 적합합니다. 바뀌는 것은 트래픽의 진입 방식이며, 모든 대상이 자동으로 원격 프록시를 거치는 것은 아닙니다. 클라이언트에 들어온 뒤에는 라우팅 규칙에 따라 직접 연결, 프록시, 차단 중 하나가 선택됩니다. 따라서 ‘Tun 사용’과 ‘전역 프록시’는 같은 개념이 아닙니다. 처리 범위가 넓어져도 실제 요구에 따라 LAN 직접 연결, 내부 DNS, 서비스별 예외를 유지해야 합니다.

데스크톱에서 v2rayN을 사용할 때는 먼저 시스템 라우팅을 가로챌 수 있는 다른 VPN이나 가상 네트워크 도구를 종료하세요. 그런 다음 플랫폼 안내에 따라 인터페이스 생성과 라우팅 변경에 필요한 권한을 부여합니다. 권한이 부족하면 UI에는 전환 완료로 표시되어도 네트워크 어댑터나 라우팅이 설정되지 않을 수 있습니다. 시작 문제를 해결하려고 방화벽을 계속 꺼 두지 마세요. 클라이언트와 시스템 로그를 확인해 권한 요청, 인터페이스 생성, 규칙 설치 중 어디에서 실패했는지 파악한 뒤 필요한 범위만 조정하세요.

시스템 프록시에서 TUN으로 단계적으로 전환

활성화하기 전에 일반 프록시 진입점에서 현재 서버가 정상인지 확인하고 기존 라우팅 모드를 기록하세요. 그런 다음 v2rayN 메인 창에서 ‘Tun 사용’을 켜고 코어가 시작되는지, 가상 네트워크 어댑터가 작동하는지 확인합니다. 첫 테스트에서는 시스템 프록시 상태를 명확하고 되돌릴 수 있게 설정하세요. 앱별 프록시, 시스템 프록시, TUN이 동시에 적용되면 원인을 파악하기 어렵습니다. 여러 진입점을 함께 사용해야 한다면 각각의 수신 주소와 트래픽 경로를 확인하세요. 진입점이 많을수록 설정이 완전해지는 것은 아닙니다.

세 가지 방향으로 테스트하세요. 시스템 프록시를 사용하지 않는 앱이 예상한 대상에 접속하는지, LAN 장비에 계속 접근할 수 있는지, DNS 조회가 설계한 대로 이뤄지는지 확인합니다. 브라우저는 시스템 프록시를 따를 수 있으므로 TUN이 실패해도 정상처럼 보일 수 있습니다. 브라우저만으로 검증하지 마세요. 내부 서비스는 도메인과 알고 있는 내부 주소로 각각 테스트하세요. 도메인 접속은 실패하지만 주소로는 성공한다면 원격 서버를 계속 바꾸기보다 DNS와 검색 도메인을 확인해야 합니다.

라우팅 루프와 가상 네트워크 어댑터 충돌

TUN을 사용할 때는 클라이언트가 원격 서버로 보내는 연결이 다시 자신에게 전달되어 루프가 생기지 않도록 해야 합니다. 클라이언트는 보통 인터페이스 바인딩, 라우팅 제외, 프로세스 처리를 통해 이를 방지하지만 사용자 지정 규칙, 여러 VPN의 동시 실행, 네트워크 인터페이스 변경으로 조건이 깨질 수 있습니다. 활성화 후 모든 연결이 시간 초과되거나 로그에서 같은 대상으로 연결을 반복한다면 먼저 새로 활성화한 트래픽 처리를 끄고 현재 기본 네트워크 어댑터와 서버 출구 경로를 확인하세요. 범위가 더 넓은 프록시 규칙을 바로 추가하지 마세요.

유선에서 무선으로 전환하거나 절전 모드에서 복귀할 때, 또는 기업 VPN에 연결할 때 인터페이스 순서와 라우팅 우선순위가 바뀔 수 있습니다. 네트워크 전환 후에만 TUN이 실패한다면 클라이언트를 다시 연결해 새 네트워크에 맞게 상태를 재설정하세요. 매번 실패한다면 더 이상 사용하지 않는 인터페이스에 고정 바인딩되어 있는지 확인합니다. Linux와 macOS는 시스템 권한, 네트워크 어댑터 이름, 라우팅 관리 방식이 서로 다르므로 Windows의 조치 방법을 그대로 적용하면 안 됩니다. 현재 클라이언트의 권한 안내와 운영체제의 네트워크 관리 방식을 따르세요.

UDP, MTU, 복구 경로

TUN이 특정 트래픽을 받는다고 해서 원격 프로토콜, 전송 방식, 서버가 같은 전달 기능을 지원한다는 뜻은 아닙니다. UDP 서비스가 실패하면 현재 연결 경로 전체가 UDP를 지원하는지 먼저 확인한 다음, 규칙이 해당 트래픽을 올바른 아웃바운드로 보내는지 살펴보세요. 대용량 응답, 파일 전송, 특정 앱만 멈추고 일반적인 짧은 요청은 정상인 경우에 MTU, 경로 MTU 탐색, 패킷 분할 문제를 검토하세요. 근거 없이 MTU를 계속 낮추지 마세요. 기존 값을 기록하고 매번 같은 서비스로 검증하세요.

클라이언트를 종료하기 전 UI에서 TUN을 끄고 정상적으로 종료해 프로그램이 라우팅과 인터페이스 상태를 복구하도록 하세요. 비정상 종료 후 네트워크가 복구되지 않으면 먼저 시스템 프록시가 중지된 로컬 포트를 가리키는지 확인하고, 다른 VPN과 남아 있는 네트워크 어댑터를 점검합니다. 필요한 경우 시스템 네트워크 설정으로 연결을 복구하되, 용도를 모르는 기업 네트워크 설정을 삭제하지 마세요. 일반 연결이 복구되면 이 장에서 다룬 최소 테스트를 다시 수행하고, 모든 기능을 곧바로 다시 켜지 마세요.

FakeDNS

합성 주소로 도메인 매핑을 저장합니다

FakeDNS는 대상의 실제 주소를 반환하는 일반 DNS 서버가 아닙니다. 전용 주소 풀에서 합성 주소를 할당하고 코어에 도메인과 주소의 대응 관계를 저장합니다. 앱이 해당 주소에 연결하면 코어가 매핑에서 원래 도메인을 복원해 라우팅과 아웃바운드 처리를 이어갑니다. 이 방식은 일부 트래픽 처리 환경에서 도메인 정보를 보존해, 분기 결정을 위해 실제 주소를 먼저 조회해야 하는 상황을 줄여줍니다. 하지만 DNS, 트래픽 처리, 도메인 복원이 모두 연결되어야 하므로 스위치 하나만 켠다고 구성이 완성되는 것은 아닙니다.

v2rayNG의 ‘설정’에서 ‘Fake DNS’ 관련 옵션을 확인하고 ‘로컬 DNS 사용’과 현재 라우팅 설정도 함께 점검하세요. 필요한 설정을 자동으로 생성하는 범위는 코어와 클라이언트마다 다르므로 실제 생성 결과와 시작 로그를 기준으로 확인해야 합니다. UI가 비슷하다는 이유만으로 v2flyNG에 같은 매개변수를 적용하지 마세요. 먼저 일반 DNS와 라우팅의 기본 상태를 검증한 뒤 FakeDNS를 테스트하세요. 일반적인 인터넷 연결도 되지 않는 단계에서 합성 주소를 추가하면 문제 진단만 복잡해집니다.

주소 풀, 조회 진입점, 복원 기능

아래는 일반적인 코어 문법의 일부 예시로, 합성 주소 풀, DNS 서비스 진입점, 인바운드 스니핑 관련 필드를 포함합니다. 각 항목은 해당 위치에 병합해야 하며, 객체 전체를 클라이언트의 스위치 옆 입력란에 임의로 붙여 넣으면 안 됩니다. 스니핑 객체는 인바운드 설정에 속합니다. 전체 설정에는 해당 트래픽을 처리할 인바운드, 라우팅, 아웃바운드도 있어야 합니다. 주소 풀이 실제 업무 네트워크와 충돌하지 않도록 하고, 임의의 공용 주소 대역을 사용하지 마세요.

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

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

위 예시의 주소 대역은 테스트 네트워크용이며, 여기서는 합성 주소 풀을 보여주기 위한 것입니다. 실제 서버 주소가 아닙니다. 주소 풀의 크기는 저장할 수 있는 매핑 수를 결정하므로 크기를 늘리는 것을 일반적인 성능 최적화로 보아서는 안 됩니다. 더 중요한 것은 앱이 받은 합성 주소가 매핑을 보유한 동일한 코어로 돌아오게 하는 것입니다. 한 클라이언트가 DNS 응답을 반환했는데 다른 VPN이 연결을 처리하거나, 코어를 재시작한 뒤에도 앱이 주소를 보관해 재사용하면 도메인 복원에 필요한 매핑이 사라질 수 있습니다.

앱 동작에 따라 적합성을 판단하세요

앱이 대부분 도메인을 통해 접속하고, 조회와 후속 연결이 같은 클라이언트에서 처리되며, 라우팅 단계에서 도메인을 안정적으로 확보하고 싶은 경우에 테스트해 볼 수 있습니다. 실제 주소로 업무 판단을 하는 앱, 조회 결과를 다른 장비에 전달해야 하는 서비스, 내부 네트워크와 테스트 주소 대역이 충돌하는 환경에는 적합하지 않을 수 있습니다. 앱에 따라 조회 주소의 특성을 확인하거나 결과를 캐시하거나 시스템 DNS를 우회할 수 있습니다. 이런 동작은 FakeDNS 결과를 일반 브라우저 테스트와 다르게 만듭니다.

앱에서 자체 암호화 DNS를 사용하면 조회가 FakeDNS 처리 모듈을 거치지 않을 수 있습니다. 이 경우 옵션을 켰는데도 대상이 실제 주소를 받더라도 반드시 코어 오류인 것은 아닙니다. 반대로 앱이 합성 주소를 받았지만 클라이언트를 우회해 직접 연결하면 접속에 실패합니다. 문제를 진단할 때는 조회가 합성 DNS에 도달했는지, 연결이 처리 대상에 포함됐는지, 코어가 도메인을 복원했는지 각각 확인하세요. 특이한 주소가 보인다는 이유만으로 전체 경로가 정상이라고 판단하지 마세요.

켜고 끌 때 모두 캐시를 처리해야 합니다

활성화한 뒤 테스트 앱을 재시작해 새 조회 요청을 보내고 일반 웹페이지, LAN 서비스, 평소 사용하는 업무 서비스를 테스트하세요. LAN 도메인이 잘못 합성되면 현재 클라이언트에서 지원하는 방법으로 내부 도메인의 실제 조회를 유지하고 해당 연결이 직접 연결되는지 확인합니다. DNS 규칙의 제외, 라우팅 규칙의 직접 연결, 시스템 라우팅의 우회는 각각 다른 단계에서 작동합니다. 하나만 설정한다고 충분한 것은 아닙니다.

FakeDNS를 끈 뒤에도 앱이나 시스템에 합성 주소가 캐시되어 있는데 코어에서 매핑이 사라지면 ‘끄고 나서 한동안 연결이 안 되는’ 현상이 생길 수 있습니다. 먼저 테스트 앱을 종료하고 관련 캐시를 정리한 뒤 새 연결을 만들어 복구 여부를 확인하세요. 클라이언트를 재시작해도 매핑 상태가 바뀔 수 있으므로 오래 실행되는 앱도 테스트해야 합니다. 작동 원리와 적용 범위는 FakeDNS 작동 원리와 적용 사례에서 더 자세히 확인할 수 있습니다.

다중 구독 관리

출처, 용도, 업데이트를 연결해 관리하세요

구독을 여러 개 관리한다면 먼저 출처마다 별도 그룹을 만들고 어떤 항목을 일상 연결에 쓸지, 어떤 항목을 호환성 테스트에만 쓸지 정하세요. 연결을 하나의 큰 목록에 합친 뒤 메모만 보고 출처를 추측하지 마세요. 그룹 이름에 ‘일상’, ‘테스트’, ‘수동 설정’처럼 용도를 표시할 수 있지만, 출처와의 대응 관계는 별도로 기록해 두어야 합니다. 계정 재설정으로 구독 주소가 바뀔 수 있으므로 이름이 같다고 해서 이전과 같은 설정 모음으로 연결된다는 보장은 없습니다.

v2rayN의 ‘구독 그룹’에서 각 그룹의 주소, 필터 조건, 업데이트 방식을 확인하고 클라이언트 옵션에 따라 업데이트 주기를 설정하세요. Android에서는 ‘구독 그룹 설정’에서 출처를 관리하고 그룹별로 업데이트할 수 있습니다. 먼저 그룹마다 개별적으로 업데이트해 각 출처가 정상적으로 파싱되는지 확인한 뒤 ‘모든 구독 업데이트’ 같은 일괄 작업을 사용하세요. 일부 업데이트가 실패해도 어떤 출처의 문제인지 바로 확인할 수 있어 모든 네트워크 오류를 클라이언트 탓으로 돌리지 않게 됩니다.

업데이트 주기와 활성 항목은 따로 관리하세요

자주 업데이트한다고 연결이 더 안정적인 것은 아닙니다. 업데이트 요청에는 네트워크와 서버 처리가 필요하며 출처의 접근 제한이 걸릴 수도 있습니다. 제공자의 이용 안내와 실제 변경 빈도에 맞춰 주기를 정하고, 지나치게 짧은 간격으로 반복 새로 고침하지 마세요. 모바일 기기는 백그라운드 실행 제한도 고려해야 합니다. 절전 정책에 따라 작업이 늦어질 수 있어 UI에서 설정한 간격대로 매번 실행된다고 보장할 수 없습니다. 사용하기 전에 특정 그룹을 직접 업데이트하고 결과를 확인하세요. 백그라운드 상태에만 의존하지 마세요.

업데이트 후 현재 활성 서버를 다시 확인하세요. 구독 업데이트로 기존 항목이 삭제되거나 메모와 보안 매개변수가 바뀔 수 있고, 클라이언트가 내부 식별자를 새로 만들 수도 있습니다. 즐겨찾기, 정렬, 라우팅 연결이 여전히 유효한지는 현재 UI에서 확인해야 합니다. 활성 이름이 같다고 매개변수도 그대로라고 생각하지 마세요. 사용자 지정 아웃바운드나 태그 참조 설정은 해당 참조가 여전히 예상한 항목을 가리키는지 추가로 확인합니다. 일상적으로 사용하는 항목에는 용도가 분명한 로컬 메모를 남겨 업데이트 후 쉽게 검토할 수 있게 하세요.

중복 항목과 기기 간 이전

여러 구독에 같은 연결이 포함되어 있거나 수동 가져오기와 구독 업데이트가 함께 이뤄져 중복 항목이 생길 수 있습니다. 메모만 비교해서는 중복 여부를 판단할 수 없습니다. 주소, 포트, 프로토콜, 보안 매개변수, 전송 설정을 함께 비교하세요. 표시 이름이 같다는 이유만으로 하나를 삭제하면 실제 용도가 다른 설정을 지울 수 있습니다. 클라이언트에 중복 제거 기능이 있다면 비교 기준을 확인하고 백업한 뒤 테스트 그룹에서 먼저 실행하세요. 출처가 다른 항목은 연결 매개변수가 같아도 업데이트 및 폐기 기준이 다를 수 있습니다.

기기 간 설정을 옮길 때는 ‘구독 출처’와 ‘기기 환경’을 구분하세요. 권한이 있는 기기 간에는 필요에 따라 구독 주소를 다시 입력할 수 있지만, 로컬 수신 포트, TUN 권한, 시스템 프록시, 앱별 프록시, 내부 DNS는 그대로 복사할 수 없는 경우가 많습니다. v2rayN의 전체 설정 파일을 v2rayNG나 v2flyNG의 백업으로 사용해서는 안 됩니다. 대상 기기에서 기본 설정을 먼저 가져온 다음 라우팅과 DNS 설정 의도를 항목별로 다시 적용하세요. 원래 기기에만 있는 경로나 인터페이스 이름을 그대로 복사하지 마세요.

만료된 구독과 인증 정보 폐기

특정 출처의 업데이트가 실패하면 재시도하려고 모든 서버를 지우지 말고, 다른 그룹의 정상 항목을 보존하세요. 실패 범위가 해당 구독에 한정되는지 확인한 뒤 주소가 만료됐는지, 로그인 후 다시 받아야 하는지, 작동하지 않는 연결을 통해 업데이트하는지 살펴보세요. 주소가 유출됐다면 구독 제공자의 재설정 기능으로 이전 링크를 폐기한 다음 기기의 그룹을 업데이트하세요. 그룹 메모만 바꿔서는 기존 주소가 무효화되지 않습니다. 다른 기기에서도 이전 링크를 계속 요청하지 않는지 확인하세요.

오랫동안 사용하지 않은 출처는 삭제하고 관련 즐겨찾기, 바로 가기, 사용자 지정 아웃바운드 참조도 확인하세요. 내보낸 백업에 이미 폐기된 링크가 남아 있을 수 있으므로 백업을 복원한 뒤에도 다시 점검해야 합니다. 다중 구독 관리의 목적은 설정마다 출처와 용도를 파악하고 개별적으로 되돌릴 수 있게 하는 것이지 목록을 계속 늘리는 것이 아닙니다. 목록 관리가 일상적인 사용을 방해한다면 복잡한 자동 선택 규칙을 추가하기 전에 중복 출처와 더 이상 쓰지 않는 항목을 줄이세요.

사용자 지정 아웃바운드

태그는 참조값이지 연결 이름이 아닙니다

아웃바운드는 코어가 대상에 연결하는 방식을 정의하고, 라우팅은 태그를 통해 사용할 아웃바운드를 선택합니다. outboundTag는 전체 설정에 이미 정의된 tag를 참조해야 하며 대소문자와 철자가 정확히 일치해야 합니다. 클라이언트 목록에 표시되는 서버 메모가 코어의 태그와 같은 것은 아닙니다. 구독 그룹 이름도 자동으로 참조 가능한 아웃바운드가 되지 않습니다. 규칙을 작성하기 전에 생성된 설정의 태그 구조를 확인하세요. 읽기 쉬운 UI 이름을 라우팅에 입력하면 코어가 해당 서버를 자동으로 찾아준다고 오해하기 쉽습니다.

아래는 직접 연결과 차단 아웃바운드의 일부 예시로, 해당 프로토콜 객체를 지원하는 Xray 또는 V2Fly 설정 환경에서 사용할 수 있습니다. 아웃바운드 두 개만 정의하며 프록시 서버, 인바운드, 전체 라우팅은 포함하지 않습니다. 이 예시로 기존 아웃바운드 목록을 덮어쓰면 원래의 프록시 연결이 사라집니다. 그래픽 클라이언트가 같은 태그를 이미 생성했을 수 있으므로 병합 전에 중복 여부를 확인하세요. 중복 태그는 참조 관계를 불분명하게 하며 표시 순서를 바꿔도 해결되지 않습니다.

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

차단 규칙과 기본 아웃바운드를 명확하게 설정하세요

차단은 접속할 필요가 없다고 확인된 대상에 사용해야 하며, 알 수 없는 연결을 전부 처리하는 간편한 방법으로 쓰면 안 됩니다. 일상 업무에 영향을 주지 않을 것이 확실한 테스트 도메인 하나로 규칙 매칭을 검증한 뒤 범위를 넓히세요. 업무 앱은 인증, 콘텐츠 로드, 업데이트를 위해 여러 도메인에 의존할 수 있습니다. 하나만 차단해도 일부 화면이 비정상적으로 보일 수 있습니다. 문제가 발생하면 더 넓은 도메인 분류를 반복 적용하는 대신 로그에서 실제 대상을 확인하세요.

{
  "type": "field",
  "domain": ["full:example.invalid"],
  "outboundTag": "block"
}

위 예시는 routing.rules 배열에 넣는 규칙 객체이며, 문법을 보여주기 위해 예약된 유효하지 않은 도메인을 사용합니다. 앞서 설명한 block 아웃바운드가 있어야 동작합니다. 실제 업무 규칙을 만들 때는 대상을 먼저 확인한 뒤 필요에 따라 전체 도메인 또는 하위 도메인 매칭을 사용하세요. 규칙에 일치하지 않는 트래픽의 기본 경로도 확인해야 합니다. 사용자 지정 설정에서 direct가 첫 번째이고 대체 규칙이 없다면 기존 클라이언트 설정과 기본 동작이 달라질 수 있습니다. 명시적인 규칙만 확인하고 검증을 끝내지 마세요.

체인 연결과 선택기는 서로 다른 개념입니다

아웃바운드가 여러 개 나란히 있으면 라우팅에서 여러 경로 중 하나를 선택할 수 있다는 뜻이지, 연결이 자동으로 체인 방식으로 구성된다는 뜻은 아닙니다. 체인 연결에는 코어에서 지원하는 아웃바운드 전달 방식과 올바른 참조 방향, 연결 가능성 설계가 필요합니다. 세부 필드와 제한은 코어마다 다릅니다. 이 기능이 필요하면 먼저 클라이언트에서 지원되는 앞단 프록시 또는 체인 연결 진입점을 제공하는지 확인하고 현재 코어 문서에 따라 설정하세요. 서버 여러 개를 배열에 순서대로 넣었다고 연결이 하나씩 거쳐 가는 것은 아닙니다.

부하 분산, 장애 조치, 수동 전환도 각각 구분해야 합니다. 선택기는 특정 조건에서 후보 아웃바운드를 선택할 뿐, 이미 연결된 세션을 자동으로 옮기지는 않습니다. 점검 대상에 접속할 수 있다고 해서 모든 업무가 정상이라는 뜻도 아닙니다. 자동 기능을 추가하기 전에 각 아웃바운드를 개별적으로 테스트해 프로토콜, 보안 매개변수, DNS 경로가 올바른지 확인한 뒤 선택 조건을 설계하세요. 구독 업데이트로 아웃바운드 태그가 다시 생성될 수 있으므로 선택기의 참조도 함께 갱신해야 합니다. 그렇지 않으면 설정이 시작되지 않거나 후보 목록이 비게 됩니다.

지원되는 진입점을 사용하고 복구용 사본을 보관하세요

v2rayN에서 사용자 지정 설정을 사용하기 전에 현재 설정을 UI가 생성하는지, 외부 파일을 사용하는지 확인하세요. 두 방식은 관리 범위가 다릅니다. UI 방식은 재시작할 때 수동 편집 내용이 덮어써질 수 있고, 사용자 지정 파일 방식은 자동 생성 기능 일부를 계속 사용하지 못할 수 있습니다. Android에서도 클라이언트가 제공하는 설정 진입점으로 가져오세요. 파일의 수명 주기를 모른 채 내부 디렉터리를 수정하지 마세요. 저장한 뒤 시작 로그에서 알 수 없는 필드, 누락된 태그, 잘못된 리소스 경로가 없는지 확인하세요.

전체 설정을 검증할 때는 인바운드 수신, DNS 조회, 규칙 매칭, 아웃바운드 연결 순으로 확인합니다. 코어가 시작되지 않으면 먼저 문법과 참조 오류를 해결하고, 코어가 시작되지만 접속할 수 없다면 트래픽 진입점과 네트워크 경로를 살펴보세요. 문제를 관찰하기 위해 로그 수준을 일시적으로 높일 수 있지만, 진단이 끝나면 평소 수준으로 되돌리고 대상 주소가 포함될 수 있는 로그를 안전하게 관리하세요. 통제되지 않는 공유 폴더에 로그를 저장하지 말고 민감한 연결 정보가 담긴 로그를 필요 이상으로 오래 보관하지 마세요.

새 아웃바운드가 명확한 요구 사항을 해결하지 못한다면 클라이언트 내장 라우팅 설정으로 돌아가 직접 관리할 항목을 줄이세요. 프로토콜과 코어의 호환성은 코어 비교 글에서 확인할 수 있습니다. 기본 연결은 시작 가이드에 따라 다시 검증하세요. 고급 설정의 완료 기준은 가능한 한 많은 옵션을 켜는 것이 아니라 모든 트래픽 경로를 설명할 수 있고 각 변경을 따로 되돌릴 수 있는 것입니다.