v2rayN
고급 설정 가이드

설정 계층 이해와 수정 전 백업

클라이언트·코어·운영체제 구분하기

v2rayN 메인 창에는 서버 정보, 구독 그룹, 라우팅 프리셋, 인터페이스 옵션이 저장됩니다. 연결을 시작하면 클라이언트가 이 정보를 바탕으로 코어 실행 설정을 만듭니다. 시스템 프록시는 운영체제 설정으로, 해당 설정을 따르는 앱에 로컬 프록시 포트를 사용하도록 안내합니다. 이 세 계층은 서로 연결되어 있지만 같은 기능은 아닙니다. 서버 목록을 바꿔도 모든 앱의 트래픽 경로가 자동으로 바뀌지는 않으며, 시스템 프록시를 전환해도 코어에 라우팅 규칙이 추가되지는 않습니다.

설정 파일을 보기 전에 클라이언트에서 현재 서버와 라우팅 프리셋, 실행 코어를 확인하고 하단 상태 표시줄과 로그를 살펴보세요. 이 사이트에서는 데스크톱용 v2rayN을 중심으로 설명하며, Android용 클라이언트는 v2rayNG, V2Fly 코어를 사용하는 대안 클라이언트는 v2flyNG입니다. 인터페이스가 비슷하다고 설정 항목까지 같지는 않습니다. 같은 공유 링크를 가져올 수 있더라도 내부에서 생성하는 설정은 다를 수 있습니다. 클라이언트를 옮길 때는 먼저 연결 정보를 가져온 다음 고급 설정을 하나씩 다시 구성하세요.

복구 가능한 기준 상태 만들기

수정하기 전에 클라이언트의 백업 또는 내보내기 기능으로 현재 설정을 저장하고, 시스템 프록시 상태와 수신 주소, 로컬 포트, 라우팅 프리셋, TUN 설정을 기록하세요. 클라이언트 데이터 폴더를 복사할 때는 먼저 클라이언트를 종료해 데이터베이스와 설정 파일이 모두 저장되도록 합니다. 백업 파일에는 구독 주소와 서버 인증 정보가 포함될 수 있으므로 안전한 로컬 위치에 보관하고, 공개된 문의 글에 첨부하지 마세요.

기준 상태는 단순히 “웹페이지가 열린다”는 뜻이 아닙니다. 평소 사용하는 앱 하나가 정상적으로 연결되는지, LAN 기기에 접속할 수 있는지, 클라이언트를 종료한 뒤 시스템 네트워크가 복구되는지도 확인하세요. 각 동작이 시스템 프록시와 TUN 중 무엇에 의존하는지 따로 기록합니다. 이후 특정 유형의 요청만 실패할 때 트래픽 진입점이나 규칙, DNS 중 어디에서 문제가 생겼는지 좁혀 볼 수 있습니다. 모든 설정을 한꺼번에 되돌릴 필요도 없습니다. 기본 연결을 다시 구성해야 한다면 사용 가이드 순서에 따라 먼저 연결을 확인한 뒤 고급 설정을 진행하세요.

한 번에 변수 하나만 변경하기

구독, 라우팅, DNS, TUN 순서로 조정하는 것이 좋습니다. 한 번에 한 가지 항목만 변경하고 저장한 뒤 다시 불러와 연결을 새로 만드세요. 이미 연결된 세션은 규칙을 바꿔도 바로 다른 경로로 이동하지 않는 경우가 많습니다. 로그를 확인할 때는 동일한 대상과 앱을 사용해 캐시, 앱의 재시도, 사이트의 일시적인 장애를 설정 변경 효과로 오해하지 않도록 하세요. 설정 두 가지를 비교하려면 “LAN 대상의 연결을 프록시에서 직접 연결로 변경”처럼 예상되는 변화를 먼저 적고 실제 아웃바운드를 확인합니다.

로그 수준도 기준을 정해 두세요. 일반적인 사용에는 클라이언트 기본값이면 충분하며, 문제를 진단할 때만 잠시 상세 수준을 높이면 됩니다. 로그에는 도메인, 주소, 경로, 구독 요청 정보가 포함될 수 있습니다. 공유하기 전에 인증 매개변수와 개인 네트워크 정보를 삭제하세요. 오류 로그는 어떤 일이 발생했는지를 보여 줄 뿐, 원인이 마지막 줄에 있다는 뜻은 아닙니다. 처음 실패한 지점부터 앞쪽으로 살펴보고 코어가 정상적으로 시작됐는지 확인한 다음 DNS와 대상 연결을 점검하세요. 뒤따라 발생한 연쇄 오류를 서로 다른 문제로 판단하지 않도록 합니다.

클라이언트가 임시로 생성한 실행 파일을 직접 수정한 뒤 계속 유지되리라 기대하지 마세요. 다시 연결하거나 서버를 전환하거나 구독을 업데이트하면 파일이 다시 생성될 수 있습니다. 그래픽 인터페이스에서 저장할 수 있는 옵션은 인터페이스에서 수정하세요. 사용자 지정 설정이 필요하다면 클라이언트가 제공하는 전용 입력 기능을 사용하고 원본을 백업합니다. JSON 문법 검사를 통과해도 현재 코어에서 지원된다는 보장은 없습니다. 알 수 없는 필드, 미지원 프로토콜, 설정 파싱 오류가 발생하면 먼저 코어 종류를 확인한 뒤 중첩 위치를 점검하세요.

이후 설정에서도 같은 원칙을 따릅니다. 클라이언트는 설정 의도를 저장하고, 코어는 규칙을 실행하며, 운영체제는 트래픽 진입점을 관리합니다. 시작 실패나 포트 충돌, 시스템 프록시가 남는 문제는 증상에 맞춰 자주 묻는 질문을 확인하세요. 메인 창 구성에 관한 설명은 v2rayN 메인 화면 기능 안내를 참고할 수 있습니다.

구독 그룹과 서버 필터링

구독마다 별도의 관리 범위 만들기

구독 그룹은 속도 측정 결과가 아니라 설정 출처에 따라 나누는 것이 좋습니다. v2rayN의 “구독 그룹”에서 그룹을 추가하고 알아보기 쉬운 메모와 구독 주소를 입력한 뒤 저장하고 업데이트하세요. 메모에는 업무용 기기 설정이나 테스트 설정처럼 출처와 용도를 적습니다. 주소에 포함된 인증 매개변수는 메모에 복사하지 마세요. 그룹을 추가한 뒤에는 해당 그룹만 업데이트해 예상한 출처의 내용인지 확인한 다음 평소 선택에 사용하세요.

“전체”는 보통 서버 목록을 모아 보여 주는 화면일 뿐, 모든 항목이 같은 구독에서 왔다는 뜻은 아닙니다. 삭제나 일괄 작업을 하기 전에는 대상 그룹으로 전환하고 현재 필터와 선택 범위를 확인하세요. 서로 다른 그룹에 같은 별칭이 있을 수 있으며, 별칭은 서버를 구분하는 고유 식별자가 아닙니다. 중복 여부를 판단할 때는 이름만 보고 삭제하지 말고 프로토콜, 대상 주소, 포트, 전송 설정을 함께 확인하세요.

목록 검색과 업데이트 필터 구분하기

서버 목록의 검색은 주로 현재 화면에 표시되는 항목에 영향을 줍니다. 구독 설정의 필터는 업데이트 후 남길 항목을 바꿀 수 있으므로 영향이 다릅니다. 목록에서 항목이 보이지 않으면 검색어를 지우고, 올바른 그룹을 선택했는지 확인한 뒤 구독 업데이트 필터를 살펴보세요. 필터 결과만 보고 구독이 비었다고 판단하지 말고, 기존에 쓸 수 있던 필터와 업데이트 설정을 잃을 수 있으니 그룹을 바로 삭제하고 다시 추가하지도 마세요.

일부 인터페이스는 키워드 일치를 사용하고, 일부 필터는 정규식을 지원합니다. 입력란의 안내를 확인하고 두 문법을 섞어 쓰지 마세요. 정규식을 지원한다고 명시되어 있다면 넓은 포함 조건부터 테스트한 뒤 조금씩 좁힙니다. 아래 식은 별칭으로 필터링하는 예시로, 명확한 이름 일부만 찾습니다. 라우팅 규칙이 아니며 트래픽이 어떤 아웃바운드를 통과할지도 결정하지 않습니다. 이름은 구독에서 제공하므로 실제 서버의 위치나 성능을 보장하지 않습니다.

홍콩|일본
^(홍콩|일본)
테스트|예비

첫 번째 줄은 이름에 두 단어 중 하나가 포함된 항목을 찾고, 두 번째 줄은 이름이 두 단어 중 하나로 시작하는 항목을 찾습니다. 세 번째 줄은 제외 정규식을 지원하는 입력란에서 사용할 수 있습니다. 각 줄은 독립된 예시이며 여러 줄을 한꺼번에 붙여 넣는 설정이 아닙니다. 필터 입력란이 하나뿐이라면 포함 조건인지 제외 조건인지 먼저 확인하세요. 정규식의 세로 막대는 “또는”을 뜻합니다. 일반적인 문자 구분 기호가 아닙니다. 구독 이름에 괄호나 더하기 기호 등이 있으면 정규식에서 이스케이프해야 할 수도 있습니다.

업데이트 전 사용 가능한 항목 보존하기

구독을 업데이트하면 해당 출처에서 관리하는 서버 정보가 바뀌는 경우가 많습니다. 구독 서버의 필드를 직접 수정해도 다음 업데이트 때 덮어써질 수 있습니다. 변경 사항을 계속 유지하려면 별도의 수동 그룹에 복사해 수정하고 용도를 메모에 적으세요. 이렇게 하면 출처에서 관리하는 정보와 로컬에서 관리하는 정보를 구분할 수 있습니다. 수동 복사본에는 구독의 이후 주소 변경이 자동 반영되지 않으므로 계속 유효한지도 주기적으로 확인하세요. 복사했다고 영구적으로 사용할 수 있는 것은 아닙니다.

필터 조건을 바꾼 뒤에는 그룹 하나만 업데이트하고 결과 안내를 확인하세요. 결과가 비어 있다면 필터 방향과 식, 구독 응답, 네트워크 연결을 차례로 점검합니다. 응답에 서버 목록 대신 오류 페이지나 로그인 안내, 사용량 안내가 포함될 수도 있습니다. 업데이트 실패가 정규식 문제라는 보장은 없습니다. 원래 그룹 정보를 유지하고 더 넓은 조건으로 되돌려 다시 시도하세요. 기존의 사용 가능한 설정을 덮어쓰도록 전체 업데이트를 연달아 실행하지 마세요.

공유 링크 가져오기와 구독 업데이트는 별개의 기능입니다. 클립보드에서 가져온 링크는 그 시점의 연결 정보를 가져오며, 구독 주소는 이후 업데이트에 사용됩니다. 같은 서버를 가져오더라도 관리 방식은 다를 수 있습니다. 계속 업데이트할 설정은 출처가 분명한 구독 그룹에 보관하고, 일회성 테스트 링크는 수동 그룹에 넣어 두면 정리하기 쉽습니다. QR 코드나 링크에는 연결 인증 정보가 포함될 수 있으므로 일반 스크린샷처럼 공개하지 마세요.

서버는 실제 연결을 확인해 선택하세요. TCP 포트에 연결할 수 있다는 것은 경로 일부에 도달했다는 뜻일 뿐, 프로토콜 핸드셰이크와 대상 DNS 확인, 웹 요청까지 성공했다는 뜻은 아닙니다. 짧은 측정 결과 하나만으로 다수의 항목을 구독 필터에서 영구 제외하지 마세요. 테스트 결과의 차이를 이해하려면 TCPing, 실제 연결 지연 시간, 다운로드 속도 측정의 차이를 참고한 뒤 평소 사용할 필터 기준을 정하세요.

라우팅 규칙 활용: 순서·매칭·아웃바운드

규칙이 처리할 트래픽부터 확인하기

라우팅 규칙은 코어에 들어온 연결만 처리합니다. 앱이 시스템 프록시를 사용하지 않고 TUN으로도 전달되지 않는다면 코어 라우팅을 바꿔도 네트워크 경로는 달라지지 않습니다. “전역” 프리셋은 일반적으로 코어에 들어온 요청이 프록시 아웃바운드를 우선 사용한다는 뜻이지, 운영체제의 모든 트래픽이 프록시로 전달된다는 뜻은 아닙니다. 규칙을 점검하기 전에 앱의 트래픽 진입점을 확인하세요. 시스템 프록시와 라우팅의 차이는 시스템 프록시와 라우팅 모드 안내를 함께 참고하세요.

v2rayN의 라우팅 설정에서 기존 프리셋을 복사한 다음 복사본에 규칙을 추가하거나 삭제하세요. 코어는 보통 위에서 아래로 규칙을 확인하며 먼저 일치하는 규칙이 아웃바운드를 결정하므로 구체적인 예외를 포괄적인 규칙보다 앞에 둡니다. 한 규칙에 도메인과 포트를 함께 지정하면 일반적으로 두 조건을 모두 만족해야 합니다. 같은 도메인 배열에 있는 항목 여러 개는 그중 하나와 일치하면 됩니다. 조건을 한 규칙에 모두 넣으면 의도보다 범위가 좁아질 수 있습니다.

검증하기 쉬운 규칙 순서 만들기

아래 예시는 먼저 LAN 도메인과 사설 대상 주소를 처리하고, 정확한 도메인을 거부하는 예시를 둔 다음 도메인 그룹을 직접 연결합니다. routing 객체만 보여 주므로 전체 설정에 direct 및 block 아웃바운드와 해당 규칙 데이터가 정의되어 있어야 합니다. 예시의 예약 도메인은 문법을 설명하기 위한 것으로 실제 서비스를 차단하라는 뜻이 아닙니다. 일치하지 않은 요청에 어떤 아웃바운드를 사용할지는 전체 설정에 따라 달라집니다.

{
  "routing": {
    "domainStrategy": "AsIs",
    "rules": [
      {
        "type": "field",
        "domain": ["domain:lan"],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "ip": ["geoip:private"],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "domain": ["full:blocked.example"],
        "outboundTag": "block"
      },
      {
        "type": "field",
        "domain": ["geosite:cn"],
        "outboundTag": "direct"
      }
    ]
  }
}

full:은 정확한 도메인과 일치하고, domain:은 도메인과 하위 도메인에 적용됩니다. geosite:는 도메인 그룹을, geoip:는 IP 주소 그룹을 참조합니다. 그룹의 존재 여부와 포함 범위는 실제로 불러온 데이터 파일에 따라 달라집니다. 규칙 데이터가 없으면 설정을 불러오지 못하거나 규칙을 사용할 수 없으므로 필드 표기만 맞다고 환경이 완전하다고 판단하지 마세요. 데이터를 업데이트하면 도메인 분류가 달라질 수 있으니 중요한 서비스는 다시 확인하세요.

geoip:private는 사설 및 기타 예약 대상 주소와 일치하며, “모든 로컬 서비스 이름”을 뜻하지는 않습니다. 도메인으로 라우터나 프린터, 내부 서비스에 접속할 때 코어가 아직 대상 주소를 얻지 못했을 수 있습니다. 특히 AsIs 정책에서는 내부 도메인 규칙을 명시해야 합니다. 기업 네트워크는 일반적인 사설 주소 대역에 포함되지 않는 내부 주소를 사용할 수도 있습니다. 이 경우 직접 연결 범위를 무작정 넓히지 말고 실제 네트워크에 맞는 CIDR을 추가하세요.

도메인 정책과 기본 처리 방식 이해하기

AsIs는 IP 규칙을 적용하기 위해 모든 도메인을 먼저 IP 주소로 변환하지 않습니다. IPIfNonMatch는 도메인 규칙과 일치하지 않을 때 주소를 조회해 IP 규칙을 적용할 수 있습니다. IPOnDemand는 주소 규칙이 필요할 때 더 적극적으로 조회합니다. 뒤의 두 정책은 라우팅 결과를 DNS 결과와 연결하며 추가 조회와 대기가 발생할 수도 있습니다. 정책을 선택하기 전에 규칙의 기준이 도메인인지 주소인지 확인하세요. 적극적인 조회가 언제나 성능을 높여 주는 것은 아닙니다.

완전한 Xray 설정에서 라우팅 규칙과 일치하지 않는 연결은 일반적으로 아웃바운드 배열의 첫 번째 항목을 사용합니다. 클라이언트 프리셋이 기본 규칙을 추가로 생성할 수도 있습니다. 따라서 일부 설정만 보고 최종 기본 동작을 추측할 수는 없습니다. 마지막 규칙을 기본 처리로 사용하려면 적용할 네트워크 유형과 대상 아웃바운드를 명시하고 이후 규칙을 먼저 처리하지 않는지 확인하세요. 프리셋을 바꾼 뒤에는 프리셋 이름만 보지 말고 클라이언트가 생성한 설정이나 라우팅 로그에서 실제 순서를 확인해야 합니다.

검증할 때는 중요한 규칙마다 반복 가능한 요청을 하나씩 지정하세요. 내부 서비스는 직접 연결을, 정확한 도메인은 지정한 아웃바운드를, 나머지 도메인은 기본 처리를 확인합니다. 매번 새 연결을 만들고 대상 도메인과 확인된 주소, 아웃바운드 태그를 기록하세요. 규칙이 적용되지 않으면 “코어에 들어왔는가, 규칙이 앞에 있는가, 조건을 모두 만족하는가, 아웃바운드 태그가 존재하는가” 순서로 확인합니다. 브라우저 캐시와 연결 재사용은 변경 사항을 가릴 수 있으므로 페이지를 새로고침해도 새 네트워크 연결이 만들어진다는 보장은 없습니다.

DNS 설정 최적화: DNS 조회 경로와 라우팅 연동

DNS 조회와 대상 연결을 따로 확인하기

한 번 접속할 때 시스템 DNS, 브라우저 보안 DNS, 클라이언트 내장 DNS, 원격 DNS 조회가 관여할 수 있습니다. 모든 조회기가 항상 사용되는 것은 아니며 같은 네트워크 경로를 사용하는 것도 아닙니다. 앱이 도메인을 프록시에 전달하면 로컬에서 대상을 먼저 조회할 필요가 없을 수도 있습니다. 반대로 앱이 먼저 주소를 받아 연결하면 코어에는 주소만 보일 수 있습니다. 최적화하기 전에 “누가, 어떤 서버에, 어느 경로로 조회하는가”를 정리하세요. 그렇지 않으면 DNS 서버를 바꿔도 실제로 사용되는 조회기는 달라지지 않을 수 있습니다.

DNS 설정의 서버 주소와 조회가 직접 연결 또는 프록시 중 어느 경로로 전달되는지는 별개의 문제입니다. 일부 코어의 내부 DNS 요청은 라우팅 규칙을 따를 수 있지만, 특수 모드에서는 일반적인 처리 과정을 우회하기도 합니다. 서버 측에서 대상을 조회하는 방식도 로컬에서 선택한 DNS와 다릅니다. 문제를 진단할 때는 클라이언트 로그에서 어떤 계층이 요청을 시작했는지 확인한 다음 DNS 조회 단계와 대상 연결 단계 중 어디에서 실패했는지 판단하세요. 대상 핸드셰이크 실패를 DNS 오염이나 DNS 서버 문제로 단정하지 마세요.

작은 범위의 DNS 분기부터 시작하기

아래는 Xray 내장 DNS를 사용하는 일부 설정 예시입니다. 일반 조회에는 공용 DNS 서버를 사용하고, 지정한 도메인 그룹과 LAN 이름에는 LAN DNS 서버를 우선 사용합니다. 192.168.1.1은 실제로 해당 주소에서 DNS를 제공하는 네트워크에서만 사용할 수 있습니다. 사용하기 전에 현재 게이트웨이나 내부 DNS의 실제 주소로 바꾸세요. 역할 설명을 위해 일반 DNS를 사용한 예시이며 모든 네트워크에 적합하거나 조회가 암호화된다는 뜻은 아닙니다.

{
  "dns": {
    "queryStrategy": "UseIPv4",
    "servers": [
      {
        "address": "192.168.1.1",
        "domains": ["geosite:cn", "domain:lan"],
        "skipFallback": true
      },
      "1.1.1.1"
    ]
  }
}

domains는 해당 서버가 우선 처리할 도메인 범위를 지정합니다. skipFallback은 다른 도메인의 일반적인 대체 선택에 이 서버가 사용되지 않도록 합니다. 이것만으로 내부 도메인이 다른 서버에 절대 전달되지 않는다고 보장할 수는 없습니다. 내부 도메인을 엄격히 분리하려면 사용 중인 코어의 대체 옵션과 실제 조회 로그도 확인해야 합니다. 내부 DNS에서 결과를 받지 못하면 공용 DNS를 무작정 대체 경로로 추가하지 말고 먼저 내부 레코드를 수정하세요. 내부 이름 정보가 관련 없는 DNS 서버에 전달될 수 있습니다.

UseIPv4는 예시용 조회 정책이지 모든 사용자가 IPv6을 끄라는 권고가 아닙니다. 네트워크에서 IPv6이 안정적으로 작동한다면 코어에 적합한 듀얼 스택 정책을 사용할 수 있습니다. IPv6 연결이 계속 실패할 때에만 주소 계열을 비교 테스트하세요. DNS에서 IPv6 주소를 받았더라도 앱이나 아웃바운드에 사용할 IPv6 경로가 없으면 대기 후 다른 경로로 전환될 수 있습니다. 시스템 주소와 기본 경로, DNS 응답, 프록시 쪽 지원 여부를 각각 확인하고 조회 결과 하나만 삭제하지 마세요.

DNS 요청이 자기 자신으로 되돌아가는 문제 방지하기

암호화 DNS 서버 주소에 도메인을 사용하면 먼저 해당 DNS 서버의 도메인을 조회해야 합니다. 이를 부트스트랩 DNS 조회라고 합니다. 아직 연결되지 않은 암호화 연결에 부트스트랩 조회까지 의존하면 순환이 생길 수 있습니다. 클라이언트에서 부트스트랩 DNS나 정적 호스트 매핑을 지원한다면 현재 코어의 안내에 따라 설정하세요. TUN을 활성화했을 때 DNS 서버 연결이 같은 진입점으로 잘못 되돌아가지 않는지도 확인합니다. 로그에 같은 조회와 연결 재시도가 반복되면 순환 여부를 점검해야 합니다.

도메인 분기와 DNS 분기는 같은 의도를 반영하는 것이 좋습니다. 내부 서비스에 직접 연결하려면 내부 네트워크에서 유효한 주소를 받아야 합니다. 프록시를 통해 접속할 대상이라면 원격 측에서 해당 주소에 도달할 수 있는지도 고려하세요. IP 주소 그룹을 사용하는 규칙은 DNS 결과에 따라 적용됩니다. DNS 서버마다 반환하는 주소가 다르면 다른 아웃바운드가 선택될 수 있습니다. 대상 경로가 자주 바뀐다면 모든 도메인을 IP 규칙에 넣기 전에 라우팅의 도메인 정책과 DNS 서버 선택을 비교하세요.

DNS를 변경한 뒤에는 캐시 적용 범위를 고려해야 합니다. 앱과 시스템, 코어가 각각 응답을 캐시할 수 있으므로 한 계층만 재시작해도 변경 사항이 적용되지 않을 수 있습니다. 먼저 앱 연결을 새로 만들고 시스템에서 제공하는 방법으로 캐시를 비우세요. 필요한 경우 클라이언트 코어를 다시 시작합니다. 브라우저에서 자체 보안 DNS를 사용하면 시스템 DNS 설정을 계속 우회할 수 있습니다. 원인을 확인할 때는 잠시 시스템 DNS를 사용해 비교한 뒤 확인이 끝나면 원래 설정으로 되돌리세요. 브라우저와 시스템, 코어의 DNS를 한꺼번에 바꾸지 마세요.

설정을 비교할 때는 앱과 대상을 동일하게 유지하고 첫 조회, 캐시가 적용된 이후의 요청, 연결을 새로 만든 경우를 각각 확인하세요. DNS 서버가 많다고 반드시 더 빠른 것은 아닙니다. 대체 경로가 많으면 경로를 예측하기 어려워질 수 있습니다. 기본 DNS 하나와 필요한 예외만 정한 뒤 세부 규칙을 추가하세요. 문제가 생기면 기존 라우팅은 유지하고 기본 DNS를 복원해 원인이 DNS 계층에 있는지 확인하기 쉽게 만드세요.

TUN 모드: 트래픽 범위와 라우팅 복구

TUN은 트래픽 진입점을 처리하며 연결 정보를 대신하지 않습니다

TUN은 가상 네트워크 인터페이스를 통해 운영체제에서 전달한 IP 트래픽을 받아 클라이언트에 포함된 네트워크 스택이나 코어 구성 요소로 처리합니다. 시스템 프록시를 따르지 않는 앱에 적합하지만 모든 프로토콜이 동일하게 작동한다는 뜻은 아닙니다. 일반 시스템 프록시는 앱이 프록시 연결을 요청할 때 주로 작동하며, TUN은 시스템 라우팅과 DNS, 가상 인터페이스에 관여합니다. 진입점은 서로 다르지만 이후에는 여전히 사용 가능한 서버와 적절한 라우팅 규칙이 필요합니다.

v2rayN에서 “TUN 모드 사용”을 활성화하기 전에 일반 프록시 방식으로 대상에 정상적으로 접속할 수 있는지 확인하세요. 서버 자체가 작동하지 않으면 TUN은 장애 범위만 넓힐 수 있습니다. 클라이언트에 관리자 권한이나 시스템 네트워크 확장 승인, 추가 구성 요소가 필요할 수 있으며 구체적인 안내는 플랫폼과 설치 방식에 따라 달라집니다. 인터페이스 안내에 따라 권한을 부여하세요. 오류를 피하려고 시스템 보호 기능을 무작정 끄거나 앱 폴더 전체를 모든 사용자가 쓸 수 있도록 설정하지 마세요.

최소한의 트래픽 인계 테스트부터 수행하기

처음 테스트할 때는 가상 네트워크 어댑터를 만들거나 기본 경로를 바꾸는 다른 소프트웨어를 종료하고 현재 네트워크 인터페이스를 기록한 다음 TUN을 활성화하세요. 시작 로그에서 인터페이스 생성이 완료됐는지 확인하고 시스템에 해당 가상 인터페이스가 표시되는지 살펴본 뒤, 원래 시스템 프록시를 사용하지 않던 앱 하나로 검증합니다. 인터페이스의 스위치가 켜져 있어도 코어가 시작되지 않았다면 트래픽이 제대로 전달되지 않을 수 있습니다. 스위치 색상만 보지 말고 로그와 실제 요청을 기준으로 판단하세요.

데스크톱 클라이언트의 TUN 화면은 서로 다른 구성 요소로 작동할 수 있으므로 Xray 라우팅 예시를 모든 TUN 설정에 적용할 수는 없습니다. 먼저 클라이언트 기본 템플릿으로 기본 동작을 확인한 뒤 제외할 네트워크 대역과 DNS 처리, 네트워크 스택 옵션을 조정하세요. Android용 v2rayNG는 시스템 VPN 인터페이스를 통해 앱 트래픽을 전달하므로 데스크톱 인터페이스와 옵션이 완전히 같지 않습니다. 적용할 앱 범위를 바꾼 뒤에는 연결을 새로 만들어야 정확히 확인할 수 있습니다.

진입점에서 제외하기와 코어에서 직접 연결하기

진입점 제외는 트래픽이 TUN에 들어오지 않도록 합니다. 코어의 direct는 트래픽이 이미 코어에 들어온 뒤 대상에 직접 연결하도록 합니다. 둘 다 LAN에 접속할 수 있지만 로그와 DNS, 시스템 라우팅에 미치는 영향은 다릅니다. 프린터나 파일 공유, 내부 서비스에 접속할 때는 먼저 해당 프로토콜이 현재 네트워크 스택에 적합한지 확인한 뒤 진입점에서 제외할지 코어에서 직접 연결할지 결정하세요. 웹페이지가 열린다고 모든 LAN 탐색 프로토콜도 작동하는 것은 아닙니다.

특히 서버 자체 연결의 출구를 주의해야 합니다. 프록시 아웃바운드에서 서버로 향하는 연결은 실제 네트워크에 도달할 수 있어야 하며, 같은 TUN 진입점으로 다시 전달되어 순환이 생겨서는 안 됩니다. 클라이언트 기본 템플릿은 보통 필요한 제외나 바인딩을 설정하지만 사용자 지정 라우팅이나 여러 가상 인터페이스, 외부 네트워크 도구로 인해 이 설정이 깨질 수 있습니다. 로그에 같은 서버 연결이 반복되거나 CPU 사용량이 비정상적으로 높고 연결이 즉시 시간 초과된다면 서버를 계속 바꾸기보다 먼저 출구 순환을 확인하세요.

시스템 프록시와 TUN을 동시에 켜는 것이 항상 잘못된 것은 아니지만 트래픽 진입점을 판단하기 어려워집니다. 일부 앱은 시스템 프록시를 통해 로컬 포트로 접속하고 다른 앱은 TUN으로 직접 전달될 수 있어 문제를 진단할 때 헷갈릴 수 있습니다. 기준 상태를 잡을 때는 시스템 프록시를 끄고 TUN만으로 확인해 보세요. 일반 프록시 모드로 돌아가려면 TUN을 끈 뒤 시스템 프록시를 켭니다. 단계마다 상태를 기록해 클라이언트를 종료한 뒤 중지된 포트를 가리키는 시스템 프록시가 남지 않도록 하세요.

절전 모드에서 깨어나거나 Wi-Fi를 바꾸거나 유선 연결을 추가하면 기본 인터페이스와 게이트웨이가 바뀔 수 있습니다. 이런 상황에서만 문제가 발생한다면 클라이언트 연결을 새로 만들고 인터페이스와 DNS가 네트워크 변경을 따라 업데이트되는지 확인하세요. 트래픽 인계 범위를 영구적으로 넓혀 복구 문제를 감추지 마세요. 테스트를 마칠 때는 TUN을 끄고 가상 경로가 제거됐는지 확인한 뒤 클라이언트를 거치지 않는 방법으로 기본 네트워크를 테스트합니다. 여전히 문제가 있으면 시스템 네트워크 설정을 항목별로 복구하세요.

FakeDNS: 가상 주소와 도메인 복원

가상 주소는 대상 서버 주소가 아닙니다

FakeDNS는 도메인에 내부용 가상 주소를 할당하고 코어에 도메인과 주소의 매핑을 저장합니다. 앱이 이 주소를 받은 뒤 연결을 시작하면 매핑을 읽을 수 있는 처리 경로로 트래픽이 다시 들어와야 코어가 도메인을 복원하고 라우팅을 계속할 수 있습니다. FakeDNS는 도메인 정보를 보존하므로 앱이 먼저 DNS 조회를 한 뒤 연결하는 상황에서 특히 유용합니다. 가상 주소 자체는 원격 서비스를 제공하지 않으며 일반 네트워크에서 직접 접속할 수도 없습니다.

따라서 DNS 서버만 바꿔서는 FakeDNS가 작동하지 않습니다. DNS 응답과 가상 대역의 트래픽 인계, 매핑 조회, 아웃바운드 처리가 함께 맞물려야 합니다. 앱이 가상 주소를 받았는데 연결이 해당 코어로 들어오지 않으면 요청 시간 초과가 발생합니다. DNS 응답은 한 프로세스가 처리하고 연결은 매핑을 공유하지 않는 다른 프로세스가 처리해도 도메인을 안정적으로 복원할 수 없습니다. 주소 풀 크기를 조정하기 전에 처리 경로를 먼저 정리하세요.

인바운드 설정과 함께 사용해야 하는 예시

아래는 Xray 형식으로 가상 주소 풀과 DNS 선택을 보여 주는 일부 설정입니다. TUN 인계와 완전한 인바운드 및 아웃바운드는 포함하지 않으므로 단독으로 실행할 수 없습니다. 주소 대역은 예약된 용도이지만 사용 전에 현재 네트워크나 다른 가상 인터페이스에서 이미 사용 중인지 확인하세요. 다른 필드 구조를 사용하는 TUN 코어에 이 설정을 그대로 붙여 넣지 마세요. 클라이언트가 완전한 FakeDNS 템플릿을 제공한다면 각 구성 요소가 일관되도록 템플릿을 우선 사용하세요.

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

이 기능을 지원하는 Xray 인바운드에는 도메인을 복원하는 기능도 필요합니다. 아래는 인바운드 객체 안의 sniffing 필드만 보여 주므로 단독 인바운드로 사용할 수 없습니다. 여기서 fakedns는 가상 주소 매핑을 이용해 대상 도메인을 복원하려는 설정이지, 모든 암호화 프로토콜의 애플리케이션 계층 내용을 읽을 수 있다는 뜻은 아닙니다. 다른 대상 탐지 옵션을 함께 활성화할지는 실제 프로토콜과 코어 동작에 따라 결정하세요.

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

주소 풀 크기는 유지할 수 있는 매핑 수를 결정할 뿐 속도를 높이지는 않습니다. 풀이 너무 작거나 동시에 처리하는 도메인이 많거나 캐시 유지 시간이 길면 기존 매핑이 교체될 수 있습니다. 앱이 이전 주소를 계속 캐시하면 이후 연결에서 도메인 정보가 사라질 수 있습니다. 풀 크기를 늘리는 것만으로 해결하려 하지 말고 메모리 사용량과 앱 캐시, 재연결 동작도 확인하세요. 간헐적인 연결 오류를 모두 해결하는 방법으로 주소 풀을 무작정 확대하지 마세요.

실제 주소가 필요한 예외 처리하기

LAN 이름과 내부 인증 서비스, DNS 주소를 다른 기기에 전달해야 하는 앱에는 실제 주소가 필요할 수 있습니다. 이런 조회는 도메인이나 용도에 따라 FakeDNS에서 제외하고 적절한 내부 DNS 서버를 사용하세요. 예외는 DNS 규칙만으로 충분하지 않으며 라우팅과도 일치해야 합니다. 실제 주소 요청은 올바른 아웃바운드를 사용하고 가상 주소 요청은 매핑 처리 경로를 벗어나지 않아야 합니다. 같은 도메인에서 실제 주소와 가상 주소가 번갈아 반환되면 먼저 DNS 서버 선택과 캐시 출처를 확인하세요.

앱 자체의 보안 DNS가 FakeDNS를 우회할 수도 있습니다. 일부 연결은 실제 주소를 사용하고 다른 연결은 가상 주소를 사용해 동작이 일관되지 않아 보일 수 있습니다. 검증할 때는 먼저 DNS 진입점을 고정하고 조회 결과가 설정한 주소 풀에 포함되는지 확인한 뒤 코어가 도메인을 복원하는지 살펴보세요. 가상 주소가 보인다고 후속 연결까지 성공한 것은 아닙니다. 요청이 예상한 도메인 규칙과 일치하고 최종적으로 실제 대상에 도달하는지도 확인해야 합니다.

안전하게 복구하려면 일반 DNS 설정을 복원하고 코어를 다시 불러온 뒤 시스템과 앱의 DNS 캐시를 비우고 연결을 새로 만드세요. 연결 풀을 유지하는 앱은 필요하다면 종료합니다. 가상 주소가 더 이상 나타나지 않는지 확인한 다음 일반 DNS 조회와 라우팅을 점검하세요. FakeDNS를 사용할 때 특정 앱만 실패한다면 주소 풀 전체를 늘리거나 모든 트래픽을 직접 연결로 바꾸지 말고 해당 앱에 제한된 예외를 설정해 비교하세요.

FakeDNS를 사용할지는 도메인 정보가 사라져 분기 처리가 어려운 문제를 해결해야 하는지에 따라 결정하면 됩니다. 기존 도메인 진입점과 일반 DNS, 라우팅이 안정적으로 작동한다면 현재 설정을 유지해도 됩니다. FakeDNS는 DNS 조회와 연결의 관계를 바꾸는 기능이지 필수 성능 옵션이 아닙니다. 처리 경로가 완결되고 예외가 명확하며 캐시 삭제와 복구 절차를 실행할 수 있어야 안정적으로 사용할 수 있습니다.

다중 구독 관리: 업데이트·중복 정리·기기 간 이전

이름 규칙과 업데이트 방식부터 정하기

여러 구독을 함께 사용할 때 문제를 일으키는 것은 대개 구독 수보다 출처와 용도가 섞이는 것입니다. 출처별로 그룹을 나누고 메모로 정식 사용, 임시 테스트, 수동 보관을 구분하세요. 그룹 이름은 안정적으로 유지하고 서버 별칭은 구독 업데이트에 따라 바뀌도록 두는 편이 좋습니다. 구독 주소에는 인증 정보가 포함될 수 있고 스크린샷이나 로그에서 안전하게 참조하기도 어려우므로 주소를 그룹 이름으로 사용하지 마세요. 그룹 순서는 사용 빈도에 따라 정해 “전체” 화면에서 매번 찾지 않도록 합니다.

자동 업데이트는 자주 할수록 좋은 것이 아니라 실제 필요에 맞춰 설정해야 합니다. 먼저 수동 업데이트가 정상적으로 되는지 확인한 뒤 적절한 주기를 설정하세요. 여러 구독이 동시에 업데이트될 때 네트워크가 아직 준비되지 않았거나 출처 응답이 느리면 오류가 겹칠 수 있습니다. 구독별 업데이트 주기를 설정할 수 있다면 테스트용과 일상용 출처를 분리하세요. 지원하지 않는다면 네트워크 전환 후 기본 연결을 확인한 다음 일괄 업데이트하세요.

구독 업데이트에 필요한 네트워크 경로 유지하기

구독 업데이트는 클라이언트 옵션에 따라 직접 연결하거나 현재 프록시를 거칠 수 있습니다. 업데이트에 현재 서버가 필요한데 그 서버가 이미 작동하지 않으면 유지 관리에 순환 의존이 생깁니다. 복구 진입점으로 최근 사용 가능 여부를 확인한 설정을 남기거나 출처에서 허용하는 네트워크에서 직접 업데이트하세요. 새 정보를 가져오기 전에 마지막으로 사용 가능한 서버 그룹을 삭제하지 마세요. 업데이트 실패가 구독 전체의 만료를 뜻하는 것도 아닙니다.

업데이트에 실패하면 먼저 연결 시간 초과와 비정상 응답 내용, 파싱 오류를 구분하세요. 연결 시간 초과는 네트워크 경로를, 비정상 응답은 구독 데이터가 반환됐는지를, 파싱 오류는 형식과 클라이언트 지원 범위를 확인합니다. 오류 페이지도 네트워크 요청 자체는 성공한 응답으로 반환될 수 있으므로 “요청 완료”가 가져오기 성공을 의미하지는 않습니다. 주소를 반복해서 붙여 넣기보다 기존 그룹을 유지하고 오류 유형을 기록하는 편이 진단에 도움이 됩니다. 오류 정보를 공유하기 전에는 주소의 인증 부분을 삭제하세요.

별칭만으로 중복을 판단하지 않기

두 구독에 같은 서버가 포함될 수도 있고 주소는 같지만 인증 정보나 전송 방식, TLS 설정이 다를 수도 있습니다. 중복을 정리할 때는 전체 연결 매개변수를 비교하고 클라이언트의 중복 제거 기능이 어떤 기준을 사용하는지 확인하세요. 별칭만으로 삭제하면 이름은 같아도 설정이 다른 항목을 잘못 지울 수 있습니다. 주소만 비교해도 다른 서비스를 하나로 합칠 수 있습니다. 실제로 정리하기 전에 백업하고 그룹 하나씩 처리한 뒤 현재 선택한 서버가 남아 있는지 확인하세요.

구독 서버가 교체되거나 삭제되면 클라이언트의 기존 선택이 무효가 되거나 다른 항목이 자동 선택될 수 있습니다. 업데이트 후에는 현재 서버와 라우팅 프리셋, 연결 상태를 확인하세요. 목록에 항목이 남아 있다는 사실만으로 세션이 복구됐다고 판단하지 마세요. 자동 선택이 테스트 결과에 의존한다면 테스트 방법이 실제 사용 목적에 맞는지도 확인해야 합니다. 안정적인 서비스 경로가 필요하다면 전체 목록을 자주 재정렬하기보다 명확한 수동 선택 절차를 관리하는 편이 문제를 찾기 쉽습니다.

실행 환경을 무작정 복사하지 말고 연결 정보만 이전하기

컴퓨터와 휴대전화에서 같은 구독 주소를 사용하면 각 기기가 같은 출처에서 정보를 가져온다는 뜻입니다. 라우팅과 DNS, 앱 적용 범위까지 자동으로 동기화되는 것은 아닙니다. v2rayNG나 v2flyNG로 옮긴 뒤에는 코어 지원 여부와 VPN 권한, 적용할 앱 범위를 다시 확인하세요. 데스크톱의 로컬 파일 경로와 수신 포트, TUN 템플릿도 다른 플랫폼에 그대로 옮기기에는 적합하지 않습니다. 대상 기기에서 기본 연결을 먼저 확인한 뒤 필요한 고급 규칙을 추가하세요.

완전한 백업은 비슷한 환경을 복원할 때, 단일 서버 공유는 임시 이전에, 구독 주소는 지속적인 관리에 적합합니다. 방식을 선택할 때 출처의 다중 기기 허용 여부와 기기 수 제한, 업데이트 주기를 고려하세요. 백업에는 서버 목록뿐 아니라 인터페이스 설정과 로컬 경로가 포함될 수도 있으므로 복원 후 로그 폴더와 수신 주소, 시작 옵션을 확인해야 합니다. 세 가지 방법을 자세히 비교하려면 컴퓨터와 휴대전화에서 설정을 함께 사용하는 방법을 참고하세요.

구독 주소가 실수로 공개되었다면 스크린샷만 삭제해서는 기존 주소를 무효화할 수 없습니다. 설정 출처의 관리 페이지에서 해당 주소를 바꾸거나 취소한 다음 각 기기를 업데이트하세요. 평소에는 인증 정보가 없는 작업 기록을 남겨 그룹의 용도와 필터 목적, 복구 절차를 정리해 둘 수 있습니다. 이렇게 하면 기기를 바꾸더라도 각 그룹의 역할을 기억에 의존하지 않고 관리 구조를 다시 만들 수 있습니다.

사용자 지정 아웃바운드: 태그·인터페이스·연결 경로

아웃바운드 태그는 설정에 실제로 있어야 합니다

아웃바운드는 코어가 연결을 다음 처리 단계로 전달하는 위치입니다. direct, block, proxy는 흔히 태그로 사용되지만, 태그는 설정에 붙이는 이름일 뿐 단어를 썼다고 기능이 자동으로 만들어지지는 않습니다. 라우팅의 outboundTag는 실제 아웃바운드 객체를 가리켜야 합니다. direct라는 태그가 다른 프로토콜에 연결되어 있다면 이름을 바꿔도 동작은 달라지지 않습니다. 사용자 지정 설정을 살펴볼 때는 태그와 프로토콜, 매개변수를 함께 확인하세요.

아래는 Xray 아웃바운드 두 개를 정의하는 예시입니다. 하나는 Freedom 프로토콜로 대상에 직접 연결하고 다른 하나는 Blackhole 프로토콜로 연결을 거부합니다. 라우팅 대상을 설명하는 용도이며 원격 프록시 서버 설정은 포함하지 않습니다. 배열의 첫 번째 항목이 직접 연결 아웃바운드이므로 라우팅 규칙과 일치하지 않는 요청은 완전한 설정에서 직접 연결될 수 있습니다. 기존 설정에 합칠 때는 순서를 다시 확인하고 클라이언트가 생성한 아웃바운드 배열을 그대로 덮어쓰지 마세요.

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

원격 프록시 아웃바운드에는 완전한 서버 정보와 인증 정보, 전송 설정, 보안 매개변수가 추가로 필요합니다. 이 페이지에서는 실제로 존재하지 않는 서버 설정을 만들지 않습니다. 실제 사용 시에는 가져온 연결 정보에서 생성한 뒤 클라이언트가 지원하는 라우팅 또는 사용자 지정 설정 기능으로 참조하세요. 클라이언트가 proxy 태그를 자동으로 생성할 수 있으므로 확인 없이 같은 이름의 객체를 다시 만들지 마세요. 태그가 중복되면 설정 오류나 예측하기 어려운 선택이 발생할 수 있습니다. 용도마다 명확하고 고유한 이름을 사용하세요.

연결이 몇 단계의 프록시를 거치는지 명확히 하기

아웃바운드가 여러 개 나란히 있다고 해서 연결 경로가 자동으로 이어지는 것은 아닙니다. 라우팅에서 아웃바운드를 선택하면 일반적으로 해당 아웃바운드가 요청을 처리합니다. 한 프록시 아웃바운드가 다른 아웃바운드를 거쳐 연결되게 하려면 코어가 명시적으로 지원하는 전달 또는 연결 체인 설정이 필요합니다. 관련 필드는 코어마다 다르므로 서로 다른 형식의 설정을 섞어 사용하지 마세요. 변경하기 전에 앱과 로컬 인바운드, 첫 번째 홉, 다음 홉, 대상을 그림으로 정리해 각 단계의 역할을 확인하세요.

연결 체인을 사용한다고 성능이 반드시 좋아지는 것은 아닙니다. 핸드셰이크와 장애 지점, 문제 진단의 복잡성이 늘어나고 DNS를 조회하는 위치도 달라질 수 있습니다. 첫 번째 홉에 도달하지 못하면 이후 설정이 올바르더라도 작동하지 않습니다. 먼저 각 아웃바운드를 따로 테스트한 뒤 조합 경로를 확인하세요. 로그에서는 프록시 서버 연결 실패와 프록시를 통한 대상 연결 실패를 구분해야 합니다. 일반 TCP 요청이 작동해도 UDP나 다른 전송 방식이 똑같이 지원된다는 보장은 없으므로 실제 서비스별로 테스트하세요.

사용자 지정 로컬 아웃바운드와 수신 범위

요청을 로컬의 다른 프록시 프로그램으로 전달하려면 상대 프로그램의 수신 주소와 포트, 프로토콜을 먼저 확인하세요. SOCKS와 HTTP 프록시는 서로 바꿔 쓸 수 있는 명칭이 아닙니다. 두 프로그램이 같은 주소와 포트를 동시에 수신할 수도 없습니다. 로컬 서비스에 연결할 때는 루프백 주소를 우선 사용하세요. LAN 기기에서도 사용해야 하는 경우에만 수신 범위를 넓히고 방화벽과 접근 제어를 함께 확인합니다. 수신 범위를 공개해도 인증 기능이 자동으로 추가되지는 않습니다.

아웃바운드에 네트워크 어댑터나 로컬 주소를 지정하는 방식은 여러 네트워크를 명확히 구분해야 할 때 유용하지만 다른 환경으로 옮기기 어렵습니다. Wi-Fi 전환이나 유선 연결 해제, 시스템 절전 이후에는 지정한 인터페이스가 사라질 수 있습니다. 출구를 고정해야 하고 관련 설정을 계속 관리할 수 있는 경우가 아니라면 시스템의 기본 라우팅을 사용하는 편이 복구하기 쉽습니다. TUN 환경에서는 인터페이스 바인딩이 가상 진입점을 우회하는지 확인해 아웃바운드 연결이 다시 자기 자신에게 전달되지 않도록 하세요. 인터페이스 설정을 바꾼 뒤에는 현재 연결만 확인하지 말고 연결을 끊었다가 다시 연결하는 테스트도 수행합니다.

사용자 지정 아웃바운드는 정확한 도메인 규칙 하나부터 검증할 수 있습니다. 테스트 대상을 새 태그로 보내고 다른 요청에는 기존 프리셋을 유지하세요. 코어가 정상적으로 시작되는지와 태그가 존재하는지, 규칙이 일치하는지, 대상 요청이 완료되는지를 확인한 다음 적용 범위를 넓힙니다. 로그에 알 수 없는 아웃바운드가 표시되면 이름 철자와 클라이언트가 객체를 덮어썼는지 확인하세요. 아웃바운드가 있는데 연결 시간이 초과되면 로컬 수신 상태와 원격 접속 가능 여부, 전송 방식 지원을 확인합니다. 설정을 불러오는 것은 시작일 뿐이며 요청이 끝까지 성공해야 검증이 완료됩니다.

일상적으로 사용할 때는 여러 단계의 사용자 지정 연결을 오래 관리하기보다 복구할 수 있는 기본 설정을 남겨 두는 것이 중요합니다. 서버를 추가해야 한다면 먼저 클라이언트 다운로드 페이지에서 사용할 클라이언트를 확인한 뒤 사용 가이드에 따라 기본 연결을 설정하세요. 기본 설정으로 구체적인 요구를 충족할 수 없을 때만 사용자 지정 아웃바운드를 추가합니다. 설정 의도와 주요 태그, 복구 방법을 기록해 다음에 수정할 때도 명확한 기준 상태에서 시작할 수 있도록 하세요.