V2Ray 고급 설정 가이드

독립적으로 업데이트할 수 있는 구독 그룹 만들기

구독 링크는 설정 목록을 가져오는 주소이지, 클라이언트가 제공하는 연결 서비스가 아닙니다. 가져오기 전에 링크 출처를 신뢰할 수 있는지, 유효 기간이 남아 있는지, 계정 관리 페이지 주소를 구독 주소로 잘못 사용하지 않았는지 확인하세요. v2rayN에서 ‘구독 그룹’을 열고 ‘구독 그룹 설정’으로 이동해 새 그룹을 만듭니다. 알아보기 쉬운 설명과 구독 주소를 입력한 뒤 저장하세요. 메뉴 배치는 화면 업데이트에 따라 달라질 수 있지만 ‘그룹 설정’과 ‘구독 업데이트’는 별개의 작업입니다. 주소를 저장하면 출처 기록만 만들어지며, 서버 설정을 가져와 해석하려면 업데이트를 실행해야 합니다.

그룹 설명에는 ‘주 구독’, ‘예비 구독’, ‘수동 설정’처럼 출처나 용도를 적는 것이 좋습니다. 날짜만 적거나 계정 비밀번호를 설명에 넣지 마세요. 그룹을 만든 뒤 메인 창으로 돌아가 업데이트할 그룹을 선택하고 ‘구독 그룹’ 메뉴에서 해당 업데이트 작업을 실행합니다. 처음에는 한 그룹만 업데이트해 새 서버 항목이 표시되는지 확인하세요. 프로토콜, 주소, 전송 설정이 올바르게 인식되는지 살펴본 다음 두 번째 출처를 추가하면, 문제가 발생했을 때 어떤 가져오기가 변화를 일으켰는지 확인하기 쉽습니다.

표시 필터와 설정 변경을 구분하기

메인 창의 그룹 선택, 검색창, 필터 기능은 대개 현재 목록의 표시만 바꾸며 트래픽에 분기 규칙을 자동으로 추가하지 않습니다. 설명으로 검색할 때는 먼저 변하지 않는 짧은 단어를 입력하고 그룹 제한도 활성화되어 있는지 확인하세요. 목록이 갑자기 비었다면 ‘현재 그룹’과 ‘검색 조건’이 함께 범위를 좁혔을 수 있습니다. 구독 내용이 삭제된 것으로 단정하지 말고 검색어를 지우고 전체 그룹으로 돌아간 뒤 다시 확인하세요. 필터 상태를 확인하기 전 같은 구독을 반복해서 추가하면 중복 항목이 생길 수 있습니다.

클라이언트에서 구독별 필터 표현식을 지원한다면 해당 항목이 포함 조건인지, 제외 조건인지, 설명 변경 규칙인지 먼저 확인하세요. 세 가지 용도를 섞어 쓰면 안 됩니다. 정규식을 지원한다고 명시된 항목에서만 정규식 문법을 사용하세요. 예를 들어 ^(工作|备用)-는 지정한 접두사로 시작하는 설명을 찾습니다. 서버의 연결 가능 여부를 확인하거나 지역명을 이해하는 표현식은 아닙니다. 먼저 일반 검색으로 대상을 확인한 다음 조건을 구독 설정으로 옮기세요. 표현식을 저장한 뒤에는 결과를 확인할 수 있도록 구독을 다시 업데이트해야 하는 경우가 많습니다.

업데이트가 실패하면 가져오기 경로 확인하기

브라우저에서 구독 주소를 열 수 있어도 클라이언트가 같은 네트워크 경로로 접속한다는 뜻은 아닙니다. 먼저 주소 전체가 올바른지 확인하세요. 복사 과정에서 줄바꿈, 공백, 끝의 문장 부호가 포함되지 않았는지 특히 살펴봅니다. 그런 다음 일반 업데이트와 프록시를 통한 업데이트를 구분하세요. 후자는 이미 작동하는 프록시 아웃바운드가 필요하므로 사용 가능한 서버가 없으면 ‘연결하려면 먼저 업데이트해야 하고, 업데이트하려면 먼저 연결해야 하는’ 순환 문제가 생길 수 있습니다. 이럴 때는 네트워크 설정을 계속 바꾸기보다 직접 접속할 수 있는 구독 주소를 사용하거나 이전에 검증한 설정을 복원하세요.

응답 내용도 확인해야 합니다. 로그인 페이지, 오류 메시지, 빈 응답은 유효한 구독 목록이 아닙니다. 공유 링크와 구독 주소도 서로 다른 입력 경로입니다. 단일 공유 링크는 클라이언트의 해당 클립보드 가져오기 기능으로 불러와야 하며, 복사할 수 있다는 이유만으로 구독 주소 입력란에 붙여 넣으면 안 됩니다. 가져오기 경로의 차이는 구독 링크 가져오기 안내를 참고하세요. 문제를 확인할 때는 오류 유형, 그룹 이름, 작업 순서만 기록하세요. 전체 구독 주소에는 계정 정보가 포함될 수 있으므로 공개 스크린샷에 올리지 마세요.

정리가 끝나면 명확한 결과가 있어야 합니다. 구독 출처마다 별도 그룹을 만들고, 수동 서버는 구독 서버와 분리해 저장하며, 필터를 끄면 전체 목록을 볼 수 있어야 합니다. 그다음 이미 작동하는 것으로 확인된 서버를 선택해 연결을 테스트하세요. 서버가 목록에 표시되는지, 선택되었는지, 실제 아웃바운드에 사용되는지는 각각 다른 상태입니다. 이후 라우팅을 설정하기 전에 이 상태들을 먼저 확인해야 합니다.

규칙 순서와 기본 아웃바운드부터 이해하기

라우팅은 커널에 이미 들어온 연결을 처리합니다. 앱이 시스템 프록시를 사용하지 않고 TUN으로도 연결되지 않았다면 라우팅을 바꿔도 앱의 접속 경로는 달라지지 않습니다. v2rayN의 ‘라우팅’ 또는 관련 설정 화면에서 현재 규칙 세트를 확인한 뒤 규칙 순서를 살펴보세요. Xray에서 흔히 쓰는 필드 기반 라우팅은 보통 위에서 아래로 규칙을 확인하고 처음 일치하는 항목의 아웃바운드를 선택합니다. 따라서 특정 도메인의 예외는 광범위한 도메인 그룹보다 위에 두고, 범위가 넓은 최종 규칙은 맨 아래에 배치해야 합니다. 설명 이름만으로 우선순위를 판단할 수는 없습니다.

하나의 필드 규칙에 서로 다른 조건 필드를 넣으면 대개 모든 조건이 함께 충족되어야 합니다. 같은 필드에 여러 값을 넣으면 보통 그중 하나만 일치해도 됩니다. 예를 들어 도메인과 포트를 함께 지정하면 대상이 도메인 조건과 포트 조건을 모두 만족해야 합니다. ‘이 도메인들이나 이 포트들’ 중 하나에 해당하면 된다는 뜻이라면 규칙을 나누세요. 규칙과 일치하지 않을 때 기본 Xray 설정은 보통 첫 번째 아웃바운드를 사용합니다. 그래픽 클라이언트가 대체 규칙을 자동 생성할 수도 있으므로 사용자 지정 항목만 보지 말고 실제 생성된 설정을 확인해야 합니다.

도메인 목록, 주소 목록 및 조회 정책

geosite:cn은 도메인 목록을 참조하고 geoip:private는 사설 주소 목록을 참조합니다. 전자는 도메인 규칙 데이터, 후자는 IP 주소 규칙 데이터에 의존합니다. 온라인 서비스 이름이 아니며 누락된 데이터 파일을 자동으로 채워 주지도 않습니다. 커널이 대상 도메인을 알아야 도메인 규칙과 일치시킬 수 있습니다. 진입 지점에서 IP만 전달되고 도메인을 복원하거나 스니핑할 정보가 없다면 도메인 규칙이 반드시 적용된다고 가정하면 안 됩니다. 반대로 도메인 대상에 IP 규칙이 적용되는지는 라우팅의 도메인 조회 정책에도 영향을 받습니다.

아래 JSON은 Xray 최상위 설정에 병합하는 예시로, 사설 주소 직접 연결, 지정 도메인 직접 연결, 광고 도메인 차단을 보여 줍니다. 직접 연결을 첫 번째 아웃바운드로 두었으므로 어떤 규칙에도 맞지 않는 연결도 직접 연결됩니다. 완성된 프록시 설정은 아닙니다. 기존 설정에 같은 이름의 아웃바운드가 있다면 중복 정의하지 말고 재사용하세요. 그래픽 클라이언트 사용자는 규칙 편집기에서 같은 규칙을 만드는 것이 좋습니다. 클라이언트가 생성한 태그도 확인하고, 규칙 배열만 받는 입력란에 JSON 전체를 붙여 넣지 마세요.

{
  "routing": {
    "domainStrategy": "AsIs",
    "rules": [
      {
        "type": "field",
        "ip": ["geoip:private"],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "domain": ["full:example.com", "geosite:cn"],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "domain": ["geosite:category-ads-all"],
        "outboundTag": "block"
      }
    ]
  },
  "outbounds": [
    {
      "tag": "direct",
      "protocol": "freedom",
      "settings": {}
    },
    {
      "tag": "block",
      "protocol": "blackhole",
      "settings": {}
    }
  ]
}

규칙을 대량으로 가져오기보다 대상 하나씩 검증하기

라우팅을 검증할 때는 재현하기 쉬운 대상을 하나 선택하고 예상 아웃바운드를 적은 뒤 로그의 실제 아웃바운드 태그를 확인하세요. 새 규칙을 저장한 다음 클라이언트 안내에 따라 설정을 다시 불러오거나 코어를 재시작하고, 앱의 기존 연결을 끊은 뒤 다시 시도해야 합니다. 장시간 연결은 이전 경로를 계속 사용할 수 있고 브라우저 캐시 때문에 페이지가 달라지지 않은 것처럼 보일 수도 있습니다. 페이지 새로고침만으로 새 규칙이 사용되었다고 판단할 수는 없습니다. 규칙이 적용되지 않으면 현재 규칙 세트, 규칙 위치, 대상 도메인 형식, 데이터 파일 사용 가능 여부, 진입 지점에서 제공되는 정보를 차례로 확인하세요.

근거리 네트워크 기기, 공유 프린터, 내부 서비스는 먼저 구체적인 주소 범위를 기준으로 확인하세요. 근거리 네트워크 문제 하나를 해결하려고 모든 트래픽을 직접 연결로 바꾸면 안 됩니다. 일부 내부 도메인은 조직 네트워크의 DNS에서만 조회되므로 DNS와 라우팅을 함께 설정해야 할 수 있습니다. 직접 연결 규칙이 적용되어도 DNS가 올바르다는 뜻은 아니며, 도메인이 조회되어도 연결이 올바른 아웃바운드로 나간다는 뜻은 아닙니다. 로그에 대상, 일치 조건, 아웃바운드 태그를 함께 기록해야 규칙 문제와 조회 문제를 구분할 수 있습니다.

마지막에는 작고 명확한 규칙 세트를 복구 기준으로 남기세요. 규칙 종류를 하나 추가할 때마다 일반 웹 페이지, 근거리 네트워크 리소스, 별도 분기가 필요한 대상을 확인합니다. 특정 도메인만 문제가 있다면 해당 예외를 추가하거나 규칙 순서를 수정하세요. 규칙 세트를 전부 지워 해결하려고 하지 마세요. 규칙이 많아질수록 용도를 분명히 기록해야 합니다. 매칭 범위를 설명할 수 없는 광범위한 규칙은 규칙이 없는 경우보다 문제 해결을 더 어렵게 만들 수 있습니다.

도메인 조회 경로부터 파악하기

DNS는 도메인을 IP 주소로 변환하지만 기기 안에는 여러 조회 경로가 동시에 존재할 수 있습니다. 시스템 리졸버는 일반 앱이 사용하고, 브라우저는 자체 보안 DNS를 사용할 수 있으며, 프록시 커널도 라우팅 판단이나 직접 연결, 상위 서버 접속을 위해 조회를 수행할 수 있습니다. 클라이언트에 ‘원격 DNS’를 입력했다고 모든 앱이 이를 사용하는 것은 아닙니다. 설정을 바꾸기 전에 대상 앱이 도메인을 프록시에 전달하는지, 아니면 로컬에서 IP로 먼저 변환한 뒤 주소를 프록시에 넘기는지 확인하세요. 두 방식은 라우팅에 제공하는 정보와 문제 해결 방법이 다릅니다.

시스템 프록시 모드에서는 프록시를 지원하는 앱이 도메인까지 로컬 프록시에 전달하는 경우가 많지만, 실제 동작은 앱과 프로토콜에 따라 달라집니다. TUN으로 연결을 가로채더라도 시스템 DNS 요청이 클라이언트에 들어오는지는 가상 네트워크 어댑터, DNS 가로채기, 제외 설정에 좌우됩니다. 브라우저 내장 암호화 DNS는 시스템 DNS 경로를 우회할 수도 있습니다. 비교 가능한 테스트 환경을 만들려면 먼저 브라우저가 시스템 조회를 사용하도록 임시 설정해 기본 경로를 확인한 뒤, 보안 DNS 설정을 별도로 살펴보세요. 두 조회 경로를 동시에 바꾸지 않는 것이 좋습니다.

서버 주소, 조회 유형, 라우팅은 서로 다른 설정입니다

DNS 서버를 선택할 때는 현재 네트워크에서 접속할 수 있는지, 내부 도메인을 조회할 수 있는지, 조회 트래픽이 어떤 경로로 나가야 하는지 고려하세요. 1.1.1.1을 입력하면 공용 리졸버 주소를 지정하는 것일 뿐, 조회를 프록시로 보내도록 자동 설정되는 것은 아닙니다. 암호화 DNS는 기기와 리졸버 사이의 조회 전송을 보호하지만 네트워크 연결 자체가 필요합니다. 리졸버 주소가 도메인이라면 그에 앞서 리졸버 도메인을 조회해야 하는 문제가 생길 수도 있습니다. 시작 단계부터 조회가 안 된다면 보조 주소를 더 추가하기보다 리졸버에 접속할 수 있는지 먼저 확인하세요.

아래는 Xray 최상위 설정의 DNS 예시로, 서버 하나와 IPv4 조회 정책만 보여 줍니다. 트래픽 진입점을 만들거나 시스템 DNS를 자동으로 바꾸는 설정은 아닙니다. 현재 커널이 해당 필드를 지원하는지 확인한 뒤 병합하세요. 클라이언트가 설정을 생성한다면 제공되는 DNS 설정 항목을 우선 사용하세요. UseIPv4는 IPv6 경로 문제를 분리해 확인할 때 유용하지만 모든 네트워크에 장기적으로 권장되는 값은 아닙니다. IPv6에 의존하는 서비스는 사용할 수 있는 주소를 얻지 못할 수 있습니다.

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

분기 조회와 캐시의 한계

내부 도메인에 접속해야 한다면 해당 도메인에 응답할 수 있는 내부 리졸버를 유지하고, 커널이 지원하는 도메인 조건에 따라 조회를 설정하세요. 공용 DNS는 조직 내부 호스트 이름을 모르는 경우가 많습니다. 분기 DNS는 모든 도메인을 모든 서버에 조회하는 방식이 아니라, 특정 도메인을 적절한 리졸버에 보내고 우선 리졸버 실패 시 대체 조회를 허용할지 명확히 정하는 방식입니다. 커널마다 서버 선택, 대체 조회, 캐시 필드가 다르므로 다른 설정 형식의 동명 필드를 그대로 복사해 사용하면 안 됩니다.

리졸버를 바꾼 뒤에도 이전 주소가 시스템 캐시, 브라우저 캐시, 앱 연결 풀에 남아 있을 수 있습니다. 먼저 대상 앱을 재시작하고 시스템 방식에 따라 DNS 캐시를 비운 뒤, 필요하면 클라이언트 코어를 다시 불러오세요. 캐시가 만료되지 않은 것을 설정 실패로 오해하거나 한 번 주소가 바뀐 것만으로 조회 품질을 판단하지 마세요. 검증할 때는 조회 성공 여부, 반환된 주소 유형, 최종 연결 성공 여부를 함께 기록합니다. 도메인은 조회되지만 대상 주소에 연결할 수 없다면 DNS를 계속 바꾸기보다 라우팅이나 네트워크 경로를 확인하세요.

DNS 오류와 인증서 오류도 구분해야 합니다. 시스템 시간이 맞지 않거나 도메인과 인증서가 일치하지 않는 경우, 앱이 내부 차단 페이지에 연결된 경우에도 웹 페이지가 열리지 않을 수 있습니다. 이런 상황에서는 리졸버를 바꿔도 해결되지 않을 수 있습니다. 특정 도메인을 고정 주소에 연결한다면 설정 이유와 복구 조건을 기록해 임시 주소가 장기간 고정되지 않도록 하세요. 제대로 된 DNS 설정은 주소를 반환하는 것뿐 아니라 라우팅, 진입점, 네트워크 환경과도 일치해야 합니다.

사용 가능한 아웃바운드를 확인한 뒤 가상 네트워크 어댑터를 활성화하세요

TUN은 시스템 라우팅 조건에 맞는 패킷을 가상 네트워크 인터페이스로 수신하므로 시스템 프록시 설정을 읽지 않는 앱을 처리하는 데 적합합니다. HTTP·SOCKS 로컬 리스너와는 다른 진입 방식이지만, 연결된 트래픽의 아웃바운드는 여전히 라우팅 규칙이 선택해야 합니다. 활성화하기 전에 일반 시스템 프록시 모드에서 서버 연결과 DNS가 정상인지 확인하세요. 기본 연결조차 되지 않은 상태에서 TUN을 켜면 가상 어댑터, 권한, 조회, 라우팅이 모두 문제에 얽혀 최초 오류 지점을 찾기 어려워집니다.

v2rayN에서 ‘TUN 활성화’ 관련 스위치를 찾기 전에 클라이언트 설치 위치가 안정적인지, 필요한 코어와 보조 구성 요소가 모두 있는지, 현재 플랫폼에서 요구하는 권한을 부여했는지 확인하세요. Windows에서는 인터페이스를 만들거나 라우팅을 조정하기 위해 관리자 권한이 필요할 수 있습니다. macOS와 Linux의 권한 방식은 클라이언트 구현에 따라 다릅니다. 다른 플랫폼의 권한 명령을 그대로 사용하지 마세요. 플랫폼별 설치 경로는 클라이언트 다운로드 페이지에서, 첫 실행의 기본 절차는 입문 가이드에서 확인하세요.

단일 진입 경로로 테스트하기

TUN을 처음 테스트할 때는 시스템 프록시를 끄고 대상 앱이 TUN만 통과하도록 설정하면 중복 진입 경로의 영향을 줄일 수 있습니다. 두 모드를 함께 사용할 수 없다는 뜻은 아닙니다. 문제 해결 단계에서는 경로를 최대한 단순하게 유지하는 것이 좋다는 의미입니다. 활성화한 뒤 클라이언트 로그에서 인터페이스 초기화 실패, 권한 부족, 라우팅 설정 실패가 있는지 확인하세요. 시스템에 가상 네트워크 어댑터가 표시되어도 DNS 가로채기와 아웃바운드가 정상이라는 보장은 없습니다. 도메인 접속, 일반 연결, 근거리 네트워크 리소스를 각각 확인해야 합니다.

다른 VPN, 가상 네트워크 어댑터 도구, 컨테이너 네트워크, 기업 보안 소프트웨어도 시스템 라우팅을 변경할 수 있습니다. 네트워크 전체가 끊기면 먼저 TUN을 끄고 복구되는지 살펴본 다음, 함께 실행 중인 구성 요소를 하나씩 확인하세요. 여러 트래픽 가로채기 도구가 동시에 실행되는 상태에서 기본 게이트웨이를 반복해서 바꾸지 마세요. 조직 네트워크나 특정 대역의 직접 연결을 유지해야 한다면 클라이언트가 지원하는 제외 라우팅 또는 규칙을 사용하고, 해당 설정이 시스템 가로채기 계층에 적용되는지 커널 분기 계층에 적용되는지 확인하세요. 이름은 비슷해도 적용 위치는 다릅니다.

DNS, 근거리 네트워크, UDP 확인하기

TUN에서 흔히 발생하는 문제는 DNS 요청이 예상한 조회 경로로 들어오지 않는 것입니다. 주소로 직접 접속되지만 도메인은 실패한다면 가상 네트워크 어댑터의 DNS, 클라이언트의 DNS 가로채기 방식, 앱 자체 조회 설정을 확인하세요. 처음부터 FakeDNS를 켜지 말고 실제 주소 조회를 기준으로 삼으면 경로를 파악하기 쉽습니다. 근거리 네트워크 접속에 문제가 있다면 사설 주소가 올바르게 제외되거나 직접 연결되는지 확인하세요. 특히 일반적이지 않은 조직 내부 대역과 특정 인터페이스로만 접근할 수 있는 내부 서비스에 유의해야 합니다.

일부 앱은 UDP를 사용하지만 진입점에서 UDP를 받을 수 있다고 해서 원격 서버, 전송 설정, 전체 네트워크 경로도 같은 트래픽을 지원하는 것은 아닙니다. 웹은 정상인데 음성 통화나 다른 UDP 기능이 작동하지 않으면 프로토콜 지원, 아웃바운드 설정, 방화벽 규칙을 따로 확인하세요. TUN 스위치만 보고 모든 앱의 트래픽을 처리한다고 판단하면 안 됩니다. MTU도 임의로 바꾸지 마세요. 특정 네트워크에서 대용량 전송이 멈추거나 연결은 되지만 데이터 전송이 계속 실패하는 등 재현 가능한 증상이 있을 때만 기존 값을 기록하고 한 번에 하나씩 테스트하세요.

명확한 종료 및 복구 절차 마련하기

TUN을 끈 뒤 일반 네트워크가 복구되었는지 확인하고, 시스템 프록시가 여전히 로컬 포트를 가리키는지도 살펴보세요. 클라이언트가 종료되었는데 시스템 프록시가 더 이상 수신하지 않는 포트를 사용하면 앱이 계속 접속하지 못할 수 있습니다. 인터페이스나 라우팅이 복구되지 않으면 클라이언트를 정상적으로 재시작한 뒤 가로채기를 다시 해제하세요. 필요하면 시스템 네트워크 관리 도구로 남은 상태를 확인합니다. 알 수 없는 라우팅을 한꺼번에 삭제하거나 시스템 가상 어댑터를 임의로 제거하지 마세요. 다른 소프트웨어에서 정상적으로 사용하는 인터페이스일 수 있습니다.

설정 후에는 정해진 순서로 다시 테스트하세요. 일반 웹 페이지, 도메인 조회가 필요한 대상, 근거리 네트워크 리소스, UDP가 필요한 앱을 확인한 다음 절전 모드 복귀와 네트워크 전환을 점검합니다. 이동하면서 유선에서 무선으로 전환하면 인터페이스와 라우팅이 바뀌어 기존 가로채기를 다시 초기화해야 할 수 있습니다. 이러한 상황을 모두 설명할 수 있을 때 TUN을 일상적인 진입 방식으로 사용하는 것이 좋습니다. 연결 문제가 생길 때마다 켜는 만능 스위치로 여기면 안 됩니다.

연결 경로에서 합성 주소가 쓰이는 위치

일반 DNS 조회는 대상의 실제 주소를 반환하고, 앱은 그 주소로 연결을 시작합니다. FakeDNS는 도메인에 주소 풀의 합성 주소를 할당하고 커널에 도메인과 합성 주소의 대응 관계를 저장합니다. 앱이 해당 주소에 연결하면 가로채기 경로가 매핑을 보유한 커널로 요청을 돌려보내야 합니다. 그래야 커널이 도메인을 복원해 라우팅하거나 아웃바운드로 전달할 수 있습니다. 주된 목적은 도메인 정보를 유지하는 것이지 대상 서버의 속도를 높이거나 모든 DNS 조회를 원격 조회로 자동 전환하는 것이 아닙니다.

이 방식은 조회 경로와 연결 경로가 하나로 이어져야 합니다. 시스템이 합성 주소를 받은 뒤 연결이 클라이언트를 우회하면 공용 인터넷에 존재하지 않는 주소에 접속하려고 합니다. 한 인스턴스가 주소를 할당했는데 연결은 매핑 정보가 없는 다른 인스턴스로 들어가도 도메인을 복원하지 못할 수 있습니다. 따라서 주소 풀 설정만 복사했다고 FakeDNS가 정상적으로 활성화된 것은 아닙니다. DNS 조회가 커널에 들어오는 경로, 앱 패킷을 가로채는 경로, 해당 인바운드가 도메인 복원 기능을 지원하는지 모두 확인해야 합니다.

주소 풀, 리졸버, 스니핑을 함께 설정하기

아래는 Xray 최상위 설정에 들어가는 FakeDNS 주소 풀과 DNS 서버 예시입니다. 198.18.0.0/15 대역의 주소를 합성 풀로 사용하지만, 대상 서버에 직접 연결할 수 있는 공용 IP 대역은 아닙니다. 이 설정은 실제 인바운드의 FakeDNS 복원 설정과 함께 사용해야 하며 클라이언트가 생성하는 TUN 설정을 대신하지 않습니다. 클라이언트에 ‘FakeDNS 활성화’ 설정이 있다면 통합된 절차를 우선 사용하세요. 서로 다른 설정 계층에 주소 풀을 중복 선언하지 않는 것이 좋습니다.

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

해당 필드를 지원하는 Xray 인바운드에서는 스니핑 설정의 destOverride에 fakedns를 포함할 수 있습니다. 이 설정은 합성 주소에서 대상 도메인을 복원하기 위한 것으로 일반 HTTP 또는 TLS 스니핑과는 다릅니다. 일반 스니핑은 연결 데이터에서 호스트 이름을 식별하려고 시도하지만 FakeDNS 복원은 앞서 만들어진 매핑에 의존합니다. 스니핑을 추가하려고 인바운드의 나머지 설정을 덮어쓰면 안 됩니다. 프로토콜, 리스닝 주소, 포트를 유지하세요. 코어와 가로채기 구현마다 설정 형식이 다르므로 실제 생성된 설정을 기준으로 해야 합니다.

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

전환 전후 캐시와 우회 경로 처리하기

FakeDNS를 켠 뒤에도 앱에 이전에 얻은 실제 주소가 캐시되어 있을 수 있습니다. 끈 뒤에는 이전 합성 주소가 남아 있을 수도 있습니다. 테스트할 때는 대상 앱의 연결을 종료하고 앱을 재시작하세요. 필요하다면 시스템 DNS 캐시를 지우고 코어를 다시 불러옵니다. 그렇지 않으면 같은 도메인에 대한 요청이 서로 다른 경로를 사용해 규칙이 간헐적으로 적용되는 것처럼 보일 수 있습니다. 특히 클라이언트를 재시작해 매핑 테이블이 사라진 뒤에도 앱에서 이전 합성 주소를 계속 사용하지 마세요. 이런 실패가 구독이나 서버 변경 때문은 아닐 수 있습니다.

가로채기를 우회해야 하는 앱은 신중하게 처리해야 합니다. 앱이 FakeDNS 합성 주소를 받았는데 프로세스 제외나 시스템 라우팅 제외 대상이면 일반 네트워크로는 해당 주소에 접속할 수 없습니다. 내부 네트워크가 합성 풀과 주소가 겹치는 경우에도 설정을 조정해야 합니다. 조회 결과를 직접 검사하거나 실제 대상 주소가 필요하거나 자체 연결 검증을 수행하는 앱은 합성 조회에 적합하지 않을 수 있습니다. 이런 대상에는 범위가 더 넓은 가로채기 규칙을 추가하기보다 실제 DNS 경로를 유지하세요.

일반 도메인 하나부터 검증하세요. 조회가 실제로 FakeDNS 응답을 받는지 확인하고, 연결이 예상한 인바운드로 들어오는지 살펴본 다음 로그에서 도메인이 복원되었는지와 해당 라우팅 규칙이 적용되었는지 확인합니다. 실제 DNS 모드에서는 정상이고 FakeDNS 모드에서만 실패한다면 서버와 라우팅은 그대로 두고 매핑 경로만 점검하세요. 그러면 구독을 다시 가져오지 않고 조회와 진입점 사이로 문제 범위를 좁힐 수 있습니다. 일반 웹 페이지 접속만 필요하다면 실제 DNS를 그대로 사용해 관리할 설정을 줄여도 됩니다.

일시적인 표시 결과가 아니라 출처를 기준으로 그룹 만들기

여러 구독을 관리할 때 첫 단계는 주소를 더 많이 가져오는 것이 아니라 각 설정의 출처를 추적할 수 있게 만드는 것입니다. 구독 주소마다 별도의 그룹을 만들고 수동 서버는 다른 그룹에 두세요. 설명이나 필터 조건으로 평소 표시 목록을 관리하면 됩니다. 이름이 비슷한 항목이 두 구독에 있다고 해서 하나의 출처 기록에 섞지 마세요. 구독 업데이트, 필터 조건, 상위 제공처의 변경은 출처별로 적용됩니다. 그룹이 뒤섞이면 항목이 사라진 이유가 제공처에서 삭제된 것인지, 필터가 바뀐 것인지, 다른 구독이 표시 결과를 덮은 것인지 판단하기 어렵습니다.

간단한 관리 기록을 남기면 충분합니다. 그룹 용도, 자동 업데이트 여부, 업데이트에 직접 연결과 프록시 중 무엇이 필요한지, 복구할 때 사용할 검증된 설정을 적어 두세요. 기록은 로컬 문서에 보관할 수 있지만 구독 주소는 민감 정보로 따로 보호해야 합니다. 클라이언트에서 설정 내보내기나 백업을 지원한다면 구독 자격 증명, 서버 인증 정보, 사용자 지정 규칙이 포함되는 범위를 먼저 확인하세요. 문제 해결 자료를 공유할 때는 필드 이름과 오류 유형만 남기고 사용자 데이터 디렉터리 전체를 보내지 마세요.

업데이트 순서와 현재 선택된 서버

업데이트 과정에서 항목이 추가되거나 제거되고 로컬 식별자가 다시 생성될 수도 있습니다. 현재 선택된 서버가 제공처에서 삭제되거나 교체되면 이후 클라이언트가 어떻게 선택할지는 구현에 따라 다르므로 항상 같은 서버를 유지한다고 가정할 수 없습니다. 중요한 사용 시간대 전에 한 그룹을 업데이트하고 현재 선택한 항목이 남아 있는지 확인한 뒤 새 연결을 설정하세요. 서버 설명이 같아도 설정이 같다는 보장은 없습니다. 프로토콜, 주소, 포트, 전송, 보안 설정이 여전히 예상과 일치하는지 살펴보세요.

이미 안정성을 확인한 출처에는 자동 업데이트가 편리하지만 기기 절전, 네트워크 전환, 업데이트 경로를 고려해야 합니다. 모든 구독을 현재 프록시를 통해 같은 시간에 업데이트하도록 설정하면 해당 프록시가 작동하지 않을 때 모두 실패할 수 있습니다. 문제를 해결하는 동안에는 수동 업데이트로 바꾸고 한 번에 한 그룹만 처리하세요. 복구한 뒤 필요한 경우 자동 업데이트를 다시 활성화하면 됩니다. 특별한 요구가 없다면 지나치게 자주 새로고침할 필요는 없습니다. 업데이트 실패가 기존 로컬 설정의 즉각적인 무효화를 뜻하지 않으므로 현재 아웃바운드가 여전히 작동하는지 먼저 확인하세요.

중복 제거, 필터링, 수동 수정

같은 서버가 여러 출처에 있을 수 있지만 ‘이름이 같다’는 것은 신뢰할 수 있는 중복 판별 조건이 아닙니다. 인증, 전송 방식, TLS 설정이 다르면 같은 주소를 가리켜도 용도가 다를 수 있습니다. 반대로 이름이 달라도 같은 설정일 수 있습니다. 클라이언트의 중복 제거 기능을 사용하기 전에 어떤 필드를 비교하는지 확인하고 복구용 사본을 보관하세요. 일상 목록을 간단히 만들려는 목적이라면 아직 이해하지 못한 설정을 삭제하기보다 그룹과 검색으로 표시 항목을 줄이세요.

구독 내용은 제공처가 관리하는 데이터입니다. 서버의 전송 매개변수를 임시로 수정하면 다음 업데이트 때 덮어쓰일 수 있습니다. 파생 설정을 계속 사용해야 한다면 수동 그룹에 복사하고 출처와 수정 이유를 기록하세요. 상위에서 생성된 설정 파일을 유일한 작업 파일처럼 직접 편집하지 마세요. 클라이언트가 다시 불러올 때 파일을 새로 생성할 수도 있습니다. 업데이트 시 서로 덮어쓰는 범위를 줄이려면 라우팅과 DNS를 클라이언트가 지원하는 별도 설정 계층에 두고 구독은 서버 매개변수만 관리하도록 하세요.

예비 그룹은 자동 장애 조치가 아닙니다

메인 창에 예비 구독을 추가하면 선택할 설정 출처가 늘어날 뿐, 상태 검사나 로드 밸런싱, 장애 조치가 자동으로 설정되는 것은 아닙니다. 관련 기능을 명시적으로 설정하지 않았다면 현재 서버에 문제가 생겼을 때 직접 선택해야 하는 경우가 많습니다. 화면에서 속도 측정이나 자동 선택을 지원하더라도 어떤 대상을 검사하는지, 실제 연결을 확인하는지, 전환이 기존 세션에 영향을 주는지 살펴보세요. 한 번 테스트에 성공했다고 모든 앱이 작동하는 것은 아니며 프로토콜과 네트워크 경로의 호환성 확인을 대신할 수도 없습니다.

여러 출처를 관리할 때 가장 중요한 것은 반복 가능한 전환 절차입니다. 현재 그룹과 서버를 기록하고 예비 설정을 선택해 연결을 다시 만든 뒤 같은 대상을 테스트하세요. 예비 설정이 작동하면 기존 출처는 그대로 두고 업데이트와 서버 매개변수를 따로 점검합니다. 모든 출처가 동시에 실패한다면 로컬 진입점, DNS, 권한, 시스템 네트워크를 확인하는 편이 좋습니다. 출처 문제와 로컬 환경 문제를 분리하면 구독을 계속 추가해 실제 설정 오류를 가리는 일을 막을 수 있습니다.

그래픽 클라이언트, 코어, 설정 형식 구분하기

v2rayN은 서버를 관리하고 설정을 생성해 코어를 실행하는 그래픽 클라이언트입니다. 프로토콜과 라우팅 처리는 선택한 코어와 관련 구성 요소가 담당합니다. 화면에 비슷한 필드가 보여도 내부 설정 형식까지 같다는 뜻은 아닙니다. 편집하기 전에 클라이언트 설정이나 시작 로그에서 현재 코어 유형을 확인하고 각 기능을 담당하는 구성 요소를 파악하세요. 특히 TUN 트래픽 가로채기와 일반 프록시 연결은 서로 다른 처리 단계에서 수행될 수 있으므로 서버 프로토콜 이름만 보고 전체 경로의 구현을 추측하면 안 됩니다.

Android에서는 v2rayNG가 주로 Xray 코어를 사용하고 v2flyNG는 V2Fly 경로의 대체 클라이언트입니다. 클라이언트를 선택할 때는 이름만 비교하지 말고 필요한 프로토콜과 기능을 먼저 확인하세요. 코어마다 프로토콜, 보안 확장, 설정 필드의 지원 범위가 다르므로 복잡한 Xray 사용자 지정 설정을 다른 코어에서 그대로 실행할 수는 없습니다. 생태계와 기능 차이는 Xray와 V2Fly 코어의 차이를 참고하세요.

아웃바운드 태그는 라우팅 참조값이지 표시용 설명이 아닙니다

사용자 지정 아웃바운드에는 알아보기 쉬운 태그, 지원되는 프로토콜, 해당 프로토콜의 매개변수가 필요합니다. 라우팅의 outboundTag는 실제 아웃바운드의 tag와 정확히 일치해야 하며 대소문자도 동일해야 합니다. 메인 창에 표시되는 서버 설명이 생성된 설정의 태그와 같다는 보장은 없습니다. 저장하기 전에 클라이언트가 아웃바운드를 유지하는지, 같은 이름의 태그가 이미 있는지, 사용자 지정 규칙이 어디에 병합되는지 확인하세요. 중복 태그나 존재하지 않는 태그를 참조하는 규칙은 시작 단계에서 먼저 처리해야 합니다.

아래 Xray 아웃바운드 객체는 연결을 로컬의 다른 SOCKS 서비스로 전달하는 예입니다. 리스닝 주소는 127.0.0.1:10810입니다. 해당 서비스가 실제로 실행 중이고 로컬 연결을 허용하는 환경에서만 사용할 수 있으며 두 번째 프록시를 자동으로 만들지는 않습니다. 객체를 지원되는 아웃바운드 배열에 넣은 뒤 해당 라우팅에서 local-socks를 참조해야 합니다. 일반 구독 서버만 사용하는 경우에는 연결을 위해 이 계층을 추가할 필요가 없는 경우가 많습니다.

{
  "tag": "local-socks",
  "protocol": "socks",
  "settings": {
    "servers": [
      {
        "address": "127.0.0.1",
        "port": 10810
      }
    ]
  }
}

전달 루프와 설정 덮어쓰기 방지하기

로컬 전달에서 가장 먼저 확인할 것은 포트 연결 관계입니다. 현재 코어의 SOCKS 인바운드도 같은 포트를 수신하는데 아웃바운드가 그 포트를 가리키면 연결이 자기 자신에게 돌아가 루프가 발생할 수 있습니다. 다른 서비스도 현재 클라이언트의 아웃바운드를 사용한다면 프로세스 간 순환 경로가 생길 수 있습니다. 설정 전에 각 단계의 리스닝 주소, 포트, 다음 홉을 적어 최종적으로 실제 네트워크 출구에 도달하는지 확인하세요. 포트를 수신하는 프로세스가 있는지만 보지 말고 어떤 프로세스인지도 확인해야 합니다.

클라이언트가 관리하는 사용자 지정 설정은 클라이언트의 사용자 지정 서버, 설정 가져오기, 규칙 편집 기능을 우선 사용하세요. 실행 중에 생성된 파일을 직접 편집하면 다음 서버 전환이나 코어 재시작 때 변경 내용이 덮어써질 수 있습니다. 전체 설정을 직접 관리해야 한다면 어떤 설정이 메인 창의 제어를 받으며 어떤 설정은 파일에서만 변경할 수 있는지 분명히 하세요. 예를 들어 전체 사용자 지정 설정에서는 메인 화면의 라우팅 선택이 더 이상 영향을 주지 않을 수 있습니다. 겉보기에는 같은데 실제로 서로 덮어쓰는 설정 출처 두 개를 동시에 관리하지 마세요.

호환성 문제의 범위를 최소화하기

코어가 시작되지 않으면 첫 번째로 확인되는 명확한 오류를 살펴보고 JSON 문법, 알 수 없는 필드, 파일 누락, 태그 참조, 포트 사용 중 문제인지 구분하세요. 코어가 시작되기도 전에 DNS나 서버를 바꾸지 마세요. 코어를 전환해야 한다면 현재 작동하는 설정을 보관하고 가장 단순하며 호환되는 연결로 기본 기능을 확인한 뒤 라우팅, 조회, 사용자 지정 아웃바운드를 하나씩 복원하세요. 클라이언트가 설정을 가져왔다는 것은 화면에서 내용을 읽었다는 뜻일 뿐, 현재 코어가 모든 필드를 실행할 수 있다는 보장은 아닙니다.

사용자 지정 아웃바운드를 일상적으로 사용하기 전에 대상 라우팅이 적용되는지, 다음 홉에 연결할 수 있는지, 앱 재연결과 종료 후 복구가 정상인지 테스트하세요. 다른 로컬 서비스에 의존하는 경로라면 서비스가 중지되었을 때의 오류도 확인해 명확한 로컬 의존성 문제를 원격 장애로 오해하지 않도록 합니다. 아웃바운드 설계의 핵심은 설명 가능성과 복구 가능성입니다. 태그마다 용도가 있어야 하고 포트마다 담당 서비스가 있어야 하며 전환 후 검증된 기본 설정으로 돌아갈 수 있어야 합니다.

먼저 오류가 발생한 단계 파악하기

‘연결할 수 없음’은 코어가 시작되지 않았거나 앱이 프록시를 사용하지 않거나 도메인 조회가 실패했거나 잘못된 아웃바운드를 선택했거나 원격 연결을 만들 수 없다는 뜻일 수 있습니다. 먼저 현재 클라이언트, 코어 유형, 진입 모드, 선택한 서버, 대상 앱, 오류가 발생한 작업을 기록해 최소 재현 절차를 만드세요. 다른 대상을 하나 더 시도해 특정 도메인만 문제인지 모든 연결이 실패하는지 확인합니다. 직접 네트워크도 이미 작동하지 않는다면 프록시 설정을 살피기 전에 시스템 네트워크를 복구하세요. 기본 네트워크 장애를 구독 문제로 오해하지 않도록 해야 합니다.

코어 시작에 실패하면 먼저 로그 첫 부분의 오류를 확인하세요. 포트 사용 중, 설정 문법 오류, 권한 부족은 대개 시작 단계에서 단서를 찾을 수 있습니다. 포트 번호는 현재 설정을 기준으로 해야 합니다. 흔히 SOCKS 포트가 10808, HTTP 포트가 10809라는 이유로 실제 기기에서도 같은 값을 쓴다고 단정하지 마세요. 포트를 바꾸면 프록시를 수동 설정한 앱도 함께 업데이트해야 합니다. 시스템 프록시 자동 설정과 앱 내부의 수동 프록시는 별개의 설정일 수 있습니다.

원격 연결보다 먼저 진입점 확인하기

시스템 프록시를 켜도 시스템 설정을 읽는 앱만 자동으로 이를 사용합니다. 시스템 프록시를 지원하지 않는 프로그램에서는 브라우저 테스트가 성공해도 해당 프로그램의 트래픽이 클라이언트에 들어왔다고 볼 수 없습니다. 먼저 프록시 지원이 확실한 앱으로 로컬 진입점을 테스트한 뒤 TUN이 필요한지 판단하세요. TUN에서는 인터페이스, 권한, 적용 범위를 확인합니다. 클라이언트 로그에 대상 연결이 전혀 나타나지 않으면 원격 프로토콜 매개변수가 아니라 진입점을 먼저 점검해야 합니다. 트래픽이 진입하지 않으면 이후 라우팅 규칙도 적용될 수 없습니다.

트래픽이 들어오는 것을 확인한 뒤 조회 오류와 연결 오류를 구분하세요. 도메인은 실패하지만 이미 알고 있는 주소로는 정상적인 경로에서 접속된다면 DNS를 확인할 수 있습니다. 다만 HTTPS에 주소를 직접 입력하면 인증서와 호스트 이름 문제가 발생할 수 있으므로 이를 DNS 문제의 근거로 삼으면 안 됩니다. 로그에서 조회 결과와 실제 연결 대상을 함께 확인하는 방법이 더 정확합니다. 주소는 조회되지만 연결 시간이 초과되면 아웃바운드와 네트워크를 확인하세요. 규칙이나 태그 오류가 바로 표시되면 먼저 설정 참조를 수정해야 합니다.

스위치를 계속 바꾸기보다 증상으로 범위 좁히기

FakeDNS를 켠 뒤에만 문제가 생기면 서버와 라우팅은 그대로 두고 실제 DNS로 돌아가 확인하세요. TUN에서만 발생한다면 일반 프록시 진입점을 비교 기준으로 유지합니다. 구독 업데이트 후 발생했다면 현재 서버가 교체되었는지, 상위 설정이 바뀌었는지 확인하세요. 코어 전환 후라면 필드 호환성과 생성된 설정부터 살펴봅니다. 각 경우에 명확한 비교 조건을 두고 서버, DNS, 라우팅을 한꺼번에 바꾼 뒤 어떤 변경이 효과가 있었는지 추측하지 마세요.

로그에서는 오류 유형과 발생 순서를 확인하세요. 연결 거부는 대상 포트가 연결을 받지 않거나 명시적으로 거부했음을 의미할 수 있습니다. 시간 초과는 네트워크 경로, 필터링, 원격 응답 지연 등이 원인일 수 있습니다. 어느 쪽도 서버 설정의 모든 필드가 올바르다는 것을 단독으로 증명하지는 않습니다. TLS 오류가 발생하면 시스템 시간, 서버 이름, 인증서 검증 설정도 확인하세요. 오류 메시지를 없애려고 보안 검증을 임의로 완화하지 마세요. 도메인, 전송 방식, 서버 설정을 일치시킨 뒤 다시 연결해야 합니다.

재사용 가능한 복구 기준 만들기

복구 기준에는 시작되는 코어, 검증된 서버, 명확한 로컬 진입점, 단순한 라우팅, 접속 가능한 DNS가 포함되어야 합니다. 변경하기 전에 기존 값과 예상 결과를 기록하고 실패하면 잘못된 상태에 설정을 계속 덧붙이지 말고 원래 값으로 되돌리세요. TUN과 FakeDNS를 사용하는 경우 복구 과정에는 앱 캐시와 시스템 가로채기 상태도 포함됩니다. 복구를 마친 뒤 연결을 새로 설정해야 합니다. 스위치를 껐다는 이유만으로 이전 경로가 완전히 정리되었다고 판단하면 안 됩니다.

문제 해결이 끝나면 유효한 변경만 남도록 설정을 정리하고 임시 테스트 규칙은 삭제하세요. 기본 연결을 빠르게 복구하려면 입문 가이드에서 기본 절차를 다시 확인하고, 설치 플랫폼이나 클라이언트를 변경하려면 다운로드 페이지에서 해당 경로를 이용하세요. 평소에도 같은 순서로 점검하면 좋습니다. 먼저 코어 실행 여부, 다음으로 트래픽 진입 여부, 그다음 조회, 라우팅, 아웃바운드를 확인하세요. 새 문제가 생겨도 설정 계층을 따라 원인을 찾을 수 있어 모든 설정을 처음부터 다시 만들 필요가 없습니다.