v2rayN 고급 설정 가이드

구독 그룹 및 서버 필터링

구독 그룹은 먼저 구독 출처를 구분하고, 서버 필터링은 그다음에 적용합니다. 구독 하나에는 보통 여러 서버 항목이 포함됩니다. 그룹에는 구독 주소, 메모, 업데이트 옵션을 저장하고, 서버 항목에는 프로토콜, 주소, 포트와 연결 매개변수를 저장합니다. 두 데이터는 서로 다른 계층입니다. 그룹 메모를 바꿔도 원격 서버 설정은 바뀌지 않으며, 로컬 항목을 삭제해도 다음 업데이트 때 다시 가져올 수 있습니다. 특정 항목을 계속 제외하려면 매번 수동으로 삭제하지 말고 그룹 필터를 사용하세요.

알아보기 쉬운 그룹 만들기

v2rayN의 구독 그룹 설정에서 새 그룹을 추가하고, 먼저 출처나 용도를 알 수 있는 메모를 입력한 다음 전체 주소를 붙여 넣으세요. 안내용 주소는 https://example.com/sub?token=xxxx입니다. 실제로 사용할 때는 본인에게 발급된 주소로 바꾸세요. 물음표 뒤의 쿼리 매개변수를 지우지 말고, 웹페이지에 표시된 주소를 구독 주소로 착각하지 마세요. 붙여 넣은 뒤 앞뒤 공백, 줄바꿈, 한글 문장부호가 들어갔는지 확인하세요. 주소에 포함된 접근 매개변수는 민감 정보로 취급해야 합니다.

우선 그룹 하나만 만들고 수동으로 업데이트해 보세요. 가져온 뒤 서버 메모, 프로토콜, 항목 수가 출처 안내와 맞는지 확인하고 다른 출처를 추가하세요. 그룹 이름은 ‘출처 약칭/용도’처럼 정하면 좋습니다. 현재 속도나 특정 테스트 결과를 이름에 쓰지 마세요. 회선 상태는 달라져도 출처는 일관되게 관리해야 합니다. 스크린샷, 로그 공유, 설정 백업을 할 때는 구독 매개변수를 가리세요. 단순한 링크라고 공개해도 되는 것은 아닙니다.

자동 업데이트를 켜기 전에 해당 그룹을 계속 동기화해야 하는지 확인하세요. 업데이트는 원격 내용을 다시 읽어 항목을 추가하거나 삭제하고, 기존 항목의 연결 매개변수를 바꿀 수도 있습니다. 구독에서 가져온 서버를 수동으로 수정해도 변경 사항이 계속 유지된다고 가정하면 안 됩니다. 특별한 매개변수가 필요한 항목은 별도 설정으로 저장하고 출처와 수정 이유를 기록하세요. 원래 구독 그룹은 동기화 용도로 유지하면, 원격 업데이트와 로컬 덮어쓰기에 동시에 의존하는 상황을 피할 수 있습니다.

필터 키워드와 정규식의 경계

필터는 보통 서버 메모를 대상으로 하지만, 실제 검색 범위와 포함·제외 방식은 클라이언트 화면에 따라 다릅니다. 먼저 명확한 일반 키워드 하나로 결과를 확인한 뒤 정규식을 사용하세요. 라우팅의 geosite:를 서버 메모 필터 칸에 입력하지 마세요. 두 기능이 처리하는 대상은 다릅니다. 필터링된 목록은 가져오거나 표시할 항목을 나타낼 뿐, 서버 연결 테스트가 완료되었다거나 지역 정보가 별도로 확인되었다는 뜻은 아닙니다.

여러 메모 조각을 일치시키려면 정규식의 세로 막대가 ‘또는’를 뜻합니다. 예: (실험|예비). 괄호 문자를 그대로 찾으려면 \(예비\)처럼 이스케이프하세요. 화면에서 요구한다고 명시하지 않는 한, 슬래시로 구분한 프로그램 코드 형식의 정규식을 그대로 붙여 넣지 마세요. 대소문자 처리와 정규식 엔진은 서로 다를 수 있습니다. 테스트할 때 일치해야 하는 항목과 일치하면 안 되는 항목을 각각 하나씩 남겨 두고 결과를 확인하는 편이 목록 길이만 보고 추측하는 것보다 정확합니다.

업데이트 실패와 빈 목록은 따로 확인

업데이트 실패는 가져오기 또는 파싱 단계에 문제가 있다는 뜻입니다. 업데이트는 성공했지만 목록이 비어 있다면 필터와 구독 내용을 확인하세요. 문제를 찾을 때는 필터 조건을 잠시 비운 뒤 해당 그룹만 업데이트하세요. 항목이 다시 나타나면 키워드를 하나씩 복원하세요. 그래도 비어 있다면 출처에서 유효한 구독 내용을 반환하는지, 인증이 만료되지는 않았는지, 응답이 로그인 페이지로 바뀌지는 않았는지 확인하세요. 오류를 가리려고 업데이트를 반복하지 마세요. 연속 요청으로 출처 측 접근 제한이 걸릴 수도 있습니다.

구독 출처에 접속하려면 이미 연결된 프록시가 필요한 네트워크라면, 클라이언트가 지원하는 경우 프록시를 통해 업데이트할 수 있습니다. 다만 이 방식은 현재 서버와 프록시 진입점에 의존하므로, 아직 가져오기에 성공하지 않은 그룹으로 그 그룹의 업데이트 경로를 만들 수는 없습니다. 사용 가능한 설정을 보존하고 직접 연결 업데이트와 프록시 업데이트의 실패 로그를 구분하세요. 자세한 점검 방법은 구독 업데이트 실패 문제 해결을 참고하세요. 공개적으로 도움을 요청할 때 전체 주소를 첨부하지 마세요.

라우팅 규칙 활용

라우팅은 요청을 순서대로 검사해 기존 아웃바운드로 전달하는 방식입니다. 규칙이 서버를 만들거나 사용할 수 없는 연결을 자동으로 고쳐 주지는 않습니다. 먼저 현재 프록시 아웃바운드가 정상인지 확인한 다음 트래픽 분할을 설정하세요. 규칙은 일치 대상, 조건, 아웃바운드 태그 순서로 살펴보세요. 도메인 조건은 도메인에, 주소 조건은 IP에 적용되며 포트와 네트워크 유형으로 범위를 더 좁힙니다. 각 계층을 분리해 봐야 규칙이 일치하거나 건너뛴 이유를 판단할 수 있습니다.

먼저 규칙 순서를 정하세요

일반적으로 규칙은 위에서 아래로 평가되며, 처음 일치한 규칙이 아웃바운드를 결정합니다. 구체적인 예외 규칙을 더 포괄적인 규칙보다 앞에 두세요. 예를 들어 특정 도메인을 프록시로 보내야 한다면, 해당 도메인이 직접 연결 도메인 목록에 속하더라도 단일 도메인 프록시 규칙을 목록 규칙보다 먼저 배치해야 합니다. 규칙을 ‘직접 연결, 프록시, 차단’ 순으로 단순 분류하지 마세요. 실제 우선순위는 예외 관계에 따라 정해야 합니다. 한 규칙 안의 서로 다른 조건은 보통 모두 충족해야 하며, 같은 종류의 목록에는 여러 후보를 넣을 수 있습니다.

다음은 Xray의 routing 부분 설정 예시입니다. block, direct, 기본 프록시 아웃바운드가 이미 있고 관련 geo 리소스도 준비되어 있어야 합니다. 광고 목록은 먼저 차단하고, 사설 주소는 그다음 직접 연결하며, 중국 도메인 목록도 직접 연결합니다. 이 조각에는 기본 프록시가 선언되어 있지 않습니다. 일치하지 않은 요청의 처리 방식은 전체 설정의 아웃바운드 순서나 클라이언트가 추가하는 대체 규칙을 확인해야 합니다.

{
  "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"
      }
    ]
  }
}

사설 주소 규칙은 LAN 접속을 보호하는 데 유용하지만 모든 경우를 해결하지는 않습니다. 앱이 도메인을 전달하고 라우팅이 AsIs를 사용하면, 이 IP 규칙을 위해 주소를 따로 조회하지 않습니다. 내부 서비스에는 명시적인 내부 도메인 규칙을 추가하고, 올바른 로컬 리졸버가 내부 도메인을 처리하도록 하세요. 공유 폴더, 프린터 서비스, 관리 페이지는 브로드캐스트나 다른 트래픽에 의존할 수도 있습니다. 웹페이지 하나가 열린다는 이유만으로 LAN 기능이 모두 정상이라고 판단하지 마세요.

도메인, IP, DNS 확인 전략

domain:example.com은 해당 도메인과 하위 도메인에 사용할 수 있고, full:example.com은 정확히 일치하는 도메인에 사용합니다. 정규식은 구조가 명확한 도메인 그룹에 적합하지만, 지나치게 포괄적인 식으로 관계없는 도메인을 같은 아웃바운드에 포함하지 않도록 주의하세요. 예시 도메인은 문법 설명용입니다. 실제 규칙에는 본인의 접속 요구사항을 반영하세요. 도메인 규칙은 URL 경로를 볼 수 없으므로 같은 도메인의 서로 다른 웹페이지를 구분할 수 없습니다.

AsIs는 요청에 현재 포함된 정보를 바탕으로 최대한 일치시킵니다. IPIfNonMatch는 도메인 규칙에 일치하지 않을 때 주소를 조회해 IP 규칙을 계속 검사합니다. IPOnDemand는 IP 정보가 필요한 규칙을 만났을 때 주소를 조회합니다. 뒤의 두 방식은 DNS 의존성과 대기 시간을 늘릴 수 있고, 조회 위치에 따라 결과가 달라질 수도 있습니다. ‘더 완전한’ 설정을 위해 무조건 적극적인 조회 전략을 선택하지 마세요. 대상 IP가 실제로 필요한 규칙인지 먼저 판단하세요.

진입점에 IP만 전달되면 도메인 규칙이 일치하지 않을 수 있습니다. 스니핑으로 앱 핸드셰이크에서 도메인 정보를 복원할 때도 있지만, 프로토콜, 암호화 방식, 클라이언트 설정에 따라 달라집니다. 스니핑이 모든 트래픽에서 도메인을 복원한다고 보장할 수는 없습니다. TUN과 FakeDNS는 도메인을 연결하는 다른 경로를 제공하지만, 트래픽이 실제로 해당 진입점을 통과하는지 확인해야 합니다. 그렇지 않으면 규칙을 올바르게 작성해도 일치시킬 정보가 없습니다.

규칙 일치 및 리소스 확인

규칙을 검증할 때는 명확한 테스트 대상을 선택하고 로그의 대상 주소, 진입점 태그, 아웃바운드 태그를 비교하세요. 한 번에 규칙 하나만 바꾼 뒤 연결을 새로 시작해 확인하세요. 기존 연결은 이전 아웃바운드를 계속 사용할 수 있습니다. 브라우저 연결 풀이나 앱의 백그라운드 연결도 결과 확인에 영향을 줍니다. 필요하면 페이지 새로고침만 하지 말고 해당 앱을 종료한 뒤 테스트하세요. 규칙 변경 후 코어 재시작이 필요한지는 클라이언트의 실제 저장 동작을 확인해야 합니다.

코어에서 geo 파일이나 목록을 찾을 수 없다고 보고하면 리소스 경로와 목록 이름부터 확인하세요. 오류를 피하려고 모든 geosite 규칙을 정규식으로 바꾸지 마세요. 리소스 내용은 출처에 따라 달라지며, 특정 태그가 존재한다고 해서 모든 사용 상황에 맞는 분류라는 뜻은 아닙니다. 자세한 로그 확인은 코어 시작 실패 및 설정 오류 분석을 참고하세요. 연결을 복구한 뒤 목록 규칙을 단계적으로 조정하세요.

DNS 설정 최적화

DNS 설정에서는 먼저 세 가지를 확인해야 합니다. 누가 조회를 시작하는지, 어느 리졸버를 사용하는지, 조회 연결이 어떤 아웃바운드를 통과하는지입니다. 시스템 리졸버, 코어 내장 DNS, 프록시 서버 측 조회가 동시에 사용될 수 있습니다. 클라이언트 화면의 ‘원격 DNS’가 모든 앱의 조회를 자동으로 처리한다는 뜻은 아닙니다. DNS 주소를 바꾸기 전에 요청 경로를 정리하면 웹 연결은 프록시를 통과하지만 도메인 조회는 다른 경로를 이용하는 상황을 놓치지 않을 수 있습니다.

라우팅용 DNS 조회와 연결용 DNS 조회 구분하기

라우팅용 DNS 조회는 IP를 얻어 규칙을 판별하는 데 쓰이고, 연결용 DNS 조회는 실제 대상 주소를 찾는 데 쓰입니다. 두 작업은 서로 다른 위치에서 수행될 수 있습니다. 도메인을 프록시 아웃바운드로 원격 전달할 때는 클라이언트가 미리 조회할 필요가 없을 수 있지만, 직접 연결 아웃바운드는 보통 로컬에서 주소를 알아야 합니다. 라우팅의 domainStrategy와 직접 연결 아웃바운드 자체의 DNS 조회 전략은 서로 다른 설정입니다. 한쪽을 조정했다고 다른 쪽도 똑같이 바뀌었다고 판단하면 안 됩니다.

다음 예시는 Xray 내장 DNS에서 도메인별 리졸버를 지정하는 방법을 보여 줍니다. 중국 도메인 목록은 로컬 시스템 리졸버를 우선 사용하고, 그 밖의 조회에는 암호화 DNS를 사용할 수 있습니다. skipFallback은 해당 서버가 일반적인 대체 선택에 참여하지 않는다는 뜻이지, 모든 대체 동작을 차단한다는 뜻은 아닙니다. 예시에는 geo 리소스가 필요합니다. 암호화 DNS 요청을 프록시로 보낼지는 라우팅과 사용 가능한 아웃바운드를 별도로 설정해야 합니다. 주소가 HTTPS를 사용한다는 이유만으로 경로가 올바르다고 판단하지 마세요.

{
  "dns": {
    "tag": "dns-query",
    "servers": [
      {
        "address": "localhost",
        "domains": ["geosite:cn"],
        "skipFallback": true
      },
      "https://1.1.1.1/dns-query"
    ],
    "queryStrategy": "UseIP"
  }
}

예시의 localhost는 시스템 DNS 동작을 사용한다는 뜻이며, 특정 로컬 수신 포트에 고정 연결한다는 뜻은 아닙니다. 현재 네트워크나 내부 DNS를 따라야 하는 경우에 적합하지만 결과가 시스템 및 네트워크 설정에 영향을 받습니다. 시스템 DNS가 TUN을 통해 코어로 다시 전달된다면 순환이 발생하는지 확인해야 합니다. ‘로컬’과 ‘직접 연결’을 같은 의미로 보면 이 의존 관계를 놓치기 쉽습니다.

DNS 조회 트래픽의 아웃바운드 지정

코어 DNS 조회를 지정한 아웃바운드로 보내려면 DNS 태그 매칭을 사용할 수 있지만, 현재 코어가 해당 요청을 어떻게 처리하는지 확인해야 합니다. 다음 규칙은 앞의 예시와 함께 사용하는 조각입니다. 먼저 일치할 수 있는 포괄적인 규칙보다 앞에 배치하세요. proxy 아웃바운드가 이미 있어야 합니다. 시스템 DNS 호출과 로컬 의미가 포함된 DNS 주소는 같은 프록시 경로를 따르지 않을 수 있으므로 각각 검증하세요. 태그만 보고 경로를 단정하면 안 됩니다.

{
  "type": "field",
  "inboundTag": ["dns-query"],
  "outboundTag": "proxy"
}

리졸버 주소가 도메인이라면 그 도메인을 처음 조회하는 방법도 필요합니다. 명확한 주소를 사용하면 초기 조회 의존성을 줄일 수 있지만, HTTPS 인증서 검증과 서비스 지원은 여전히 올바르게 설정해야 합니다. 경로 문제를 해결하려고 인증서 검증을 끄지 마세요. 프록시 서버 주소를 내장 DNS로 조회해야 하는데 DNS가 다시 해당 프록시 연결에 의존한다면 시작 과정에서 순환이 생길 수 있습니다. 서버 주소를 독립적으로 조회할 수 있는 경로를 마련하거나 시스템에서 초기 조회를 처리하세요.

듀얼 스택, 캐시, 문제 해결

UseIP는 설정에 따라 주소 계열을 가져오도록 합니다. IPv4 또는 IPv6만 선택하려면 명확한 이유가 있어야 합니다. 네트워크에 IPv6 주소가 있다고 해서 IPv6 경로와 출구까지 정상이라는 뜻은 아닙니다. 일부 웹사이트가 오래 대기한다면 주소 계열을 하나씩 임시로 테스트해 오류와 연결 동작을 비교하세요. IPv6 지원을 영구적으로 모두 삭제하지 마세요. 사용하는 코어가 해당 필드와 값을 지원하는지도 확인해야 합니다. 다른 코어의 확장 옵션을 그대로 가져오면 안 됩니다.

리졸버를 바꾼 뒤에도 시스템, 브라우저, 코어 캐시에 이전 결과가 남아 있을 수 있습니다. 문제를 해결할 때는 조회 결과와 실제 연결 대상을 각각 살펴보고, 필요한 경우 코어나 앱을 재시작하세요. 매번 기기 전체의 네트워크 설정을 초기화할 필요는 없습니다. 앱 자체의 암호화 DNS가 시스템 설정을 우회할 수도 있습니다. 앱에서 해당 기능을 켰는지 먼저 확인한 뒤 독립적으로 유지할지 시스템 DNS를 사용하게 할지 결정하세요. 서로 다른 두 정책이 충돌하지 않도록 주의해야 합니다.

도메인은 조회되지만 웹페이지가 열리지 않는다면 라우팅, 연결, 서버 기능을 계속 확인하세요. 도메인 조회 결과 자체가 없다면 리졸버 연결성, 조회 아웃바운드, 내부 도메인, 주소 계열 제한을 점검하세요. 실패한 조회 한 건과 그에 인접한 연결 로그를 기록하면 여러 DNS 주소를 한꺼번에 바꾸는 것보다 원인을 찾는 데 도움이 됩니다. DNS 최적화의 목표는 경로를 설명할 수 있고 접속 위치에 맞는 결과를 얻는 것입니다. 단순히 더 빨라 보이는 주소를 고르는 것이 아닙니다.

TUN 모드

TUN은 가상 네트워크 인터페이스로 트래픽을 받아 시스템 프록시 설정을 따르지 않는 앱에 사용할 수 있습니다. 바뀌는 것은 트래픽 진입점이지 서버 프로토콜이나 독립적인 연결 서비스가 아닙니다. v2rayN의 시스템 프록시는 시스템 프록시를 읽는 앱에 주로 영향을 줍니다. TUN은 인터페이스, 라우팅, 관련 네트워크 스택에 의존합니다. TUN을 켠 뒤에도 사용 가능한 프록시 아웃바운드와 올바른 DNS 경로가 필요합니다. TUN 스위치로 앞서 수행한 연결 검증을 대신할 수는 없습니다.

활성화 전에 네트워크 기준 상태 기록

먼저 일반 프록시 모드에서 서버 연결을 확인한 다음 현재 기본 게이트웨이, DNS 설정, 기존 가상 인터페이스, 자주 사용하는 내부 주소를 기록하세요. 회사 네트워크, 원격 데스크톱, 가상 머신을 사용하는 경우 특히 가로채면 안 되는 트래픽을 확인해야 합니다. 기존 터널, 컨테이너, 가상 머신 소프트웨어가 라우트를 설치했을 수도 있습니다. 기본 상태를 모르면 TUN을 켠 뒤 생긴 문제가 새 규칙 때문인지 원래 네트워크 경로에 문제가 있었는지 구분하기 어렵습니다.

Windows에서는 인터페이스 생성이나 시스템 라우트 변경에 관리자 권한이 필요한 경우가 많습니다. macOS와 Linux에서는 해당 시스템의 권한이나 인증 설정이 필요합니다. v2rayN의 화면 이름, 보조 구성 요소, 시작 방식은 바뀔 수 있으므로 현재 설정 안내를 따르세요. Android의 v2rayNG와 v2flyNG는 보통 시스템에서 제공하는 터널 권한으로 트래픽을 처리합니다. 이 권한은 데스크톱의 관리자 실행과 다르므로 데스크톱 권한 설정을 그대로 적용하지 마세요.

처음 전환할 때는 시스템 프록시를 끈 뒤 TUN을 켜면 두 진입점이 동시에 작동하는 변수를 줄일 수 있습니다. 여기서 ‘시스템 프록시 지우기’는 앱의 접속 진입점을 조정한다는 뜻이지 프록시 코어를 종료한다는 뜻은 아닙니다. 가상 인터페이스가 정상적으로 생성되었는지 확인한 다음 기본 라우트와 DNS가 예상대로 바뀌었는지 살펴보세요. 현재 연결을 원격 장비 관리에 사용하고 있다면 트래픽 경로를 인계한 뒤 조작이 불가능해지지 않도록 로컬 롤백 방법을 먼저 준비하세요.

스택, 라우트, 제외 항목

스택은 가상 인터페이스에서 받은 데이터를 처리하는 방식을 결정합니다. 흔히 시스템 스택과 gvisor가 있지만 실제 선택지는 사용 중인 구현에 따라 다릅니다. 옵션마다 프로토콜 호환성, 리소스 사용량, 플랫폼 지원에 차이가 있습니다. 이름만 보고 속도를 판단하지 마세요. 먼저 클라이언트가 권장하는 기본 옵션을 사용하고, 특정 앱의 호환성 문제가 있을 때 동일한 대상과 아웃바운드로 비교 테스트하세요. 서버 상태 변화를 스택 차이로 오해하지 않도록 주의해야 합니다.

프록시 서버 연결이 TUN으로 되돌아오는 순환을 방지해야 합니다. 클라이언트는 보통 인터페이스 바인딩, 라우트 제외 등의 방식으로 이 아웃바운드 경로를 보호하지만 사용자 지정 설정이 보호 조건을 깨뜨릴 수 있습니다. 시작 후 일반 네트워크와 프록시가 모두 끊기거나 로그에서 같은 주소로 연결을 반복하는 문제가 나타날 수 있습니다. 기본 라우트를 계속 추가하지 말고 서버 주소가 실제로 어느 경로로 나가는지 확인하세요. 서버 주소가 도메인이라면 주소가 바뀐 뒤에도 제외 설정이 유효한지 살펴봐야 합니다.

LAN 제외 범위는 실제 주소 대역에 맞춰 설정해야 합니다. 가정에서 흔히 쓰는 대역만으로는 회사, 가상 머신, 전용 네트워크를 모두 포함할 수 없습니다. 사설 주소 한 대역만 제외하면 다른 내부 대역을 놓칠 수 있고, 범위를 지나치게 넓히면 프록시로 보내야 할 요청이 직접 전송될 수 있습니다. 먼저 필요한 네트워크 대역과 내부 도메인을 파악한 다음 클라이언트가 지원하는 라우트 제외나 직접 연결 규칙을 선택하세요. 라우팅만 가능하고 내부 이름을 조회할 수 없는 상황을 막으려면 DNS도 함께 설정해야 합니다.

트래픽 인계 효과와 종료 후 복구

검증할 때는 시스템 프록시를 읽지 않는 앱을 선택해 요청이 TUN으로 들어가는지 확인한 다음 웹, LAN, UDP가 필요한 기능을 각각 테스트하세요. UDP 실패는 아웃바운드 기능, 방화벽, 원격 제한, 스택 구현 등 여러 원인에서 발생할 수 있습니다. 모두 TUN 문제라고 단정하지 마세요. 브라우저에서 페이지가 열린다는 사실은 한 종류의 요청이 성공했다는 뜻일 뿐, 모든 시스템 트래픽이 인계되었다는 증거는 아닙니다. 가상 인터페이스가 존재하는 것만으로 실제 연결 테스트를 대신할 수도 없습니다.

TUN을 켠 뒤 네트워크가 끊기면 먼저 TUN을 끄고 일반 네트워크가 복구되는지 확인하세요. 그다음 코어를 종료하고 남아 있는 인터페이스, 라우트, DNS 설정을 점검합니다. 먼저 클라이언트의 정상 종료 절차를 사용하세요. 가상 네트워크 어댑터를 모두 삭제하거나 전체 네트워크를 초기화하지 마세요. 기준 상태를 복원한 뒤 권한, 진입점, 서버 아웃바운드, DNS 네 계층을 차례로 다시 확인하세요. 설정 개념은 용어 설명에서 확인한 다음 현재 플랫폼의 설정 화면으로 돌아오면 됩니다.

FakeDNS와 도메인 연결

FakeDNS는 대상 서버의 실제 주소가 아닌 내부 매핑용 주소를 반환합니다. 코어는 ‘도메인과 합성 주소’의 연결 정보를 저장하고, 이후 매핑 복구를 지원하는 진입점으로 요청이 들어오면 도메인을 복원해 아웃바운드를 선택합니다. FakeDNS는 도메인 정보를 유지해 도메인 라우팅을 돕는 기능이지 일반적인 DNS 가속 옵션이 아닙니다. DNS 조회, 후속 연결, 매핑 복구가 하나의 처리 경로 안에 있는지 확인해야 합니다. 그렇지 않으면 합성 주소가 접속할 수 없는 대상으로 남습니다.

전체 처리 경로 이해하기

전체 과정은 앱의 도메인 조회, FakeDNS에 도달한 조회 요청, 합성 주소 응답, 앱의 해당 주소 연결, 진입점에서 도메인 복원, 실제 대상에 대한 아웃바운드 연결로 이어집니다. 어느 한 단계라도 코어를 우회하면 실패할 수 있습니다. 예를 들어 앱이 다른 암호화 DNS를 사용하면 합성 주소를 받지 못할 수 있고, 합성 주소를 받았더라도 연결이 TUN을 우회하면 도메인이 복원되지 않습니다. DNS 서버를 fakedns로 바꾸는 것만으로 전체 설정이 완료되지는 않습니다.

다음은 Xray의 FakeDNS 풀과 내장 DNS 설정 조각입니다. 선택한 대역은 벤치마크용 주소 범위에 속하지만, 로컬에서 이미 같은 대역을 사용 중인지 확인해야 합니다. poolSize는 매핑 풀의 크기를 제어하며 공개 서버용으로 예약되는 주소 수를 뜻하지 않습니다. 예시는 구조 설명용입니다. 실제 진입점에는 스니핑과 라우팅 설정도 필요합니다. v2rayN에서 다른 네트워크 구성 요소로 TUN을 처리한다면 해당 구성 요소의 설정 방식을 따르세요. 서로 다른 구현의 필드를 섞어 쓰지 마세요.

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

진입점은 FakeDNS 주소를 식별하고 도메인을 복원할 수 있어야 합니다. 다음은 Xray 진입점에서 사용할 수 있는 sniffing 부분 객체이며, 독립된 진입점 정의가 아닙니다. metadataOnly는 메타데이터 스니핑만 허용하며 매핑 복구 경로를 설명하는 데 적합합니다. HTTP 또는 TLS 스니핑도 필요하다면 대상 목록과 옵션을 다시 확인하세요. 서로 다른 출처의 스니핑 설정 조각을 겹쳐 붙인 뒤 자동으로 함께 동작한다고 가정하지 마세요.

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

주소 풀, 예외, 호환성

주소 풀은 실제 사용 중인 매핑을 수용할 만큼 충분해야 하지만 기존 네트워크와 겹쳐서는 안 됩니다. 매핑 공간과 풀 크기는 서로 다른 개념이며, 크기를 늘려도 진입점이 트래픽을 처리하지 않는 문제는 해결되지 않습니다. 잦은 재시작으로 매핑 상태가 사라져도 앱 캐시에는 이전 주소가 남을 수 있습니다. 앱이 오래된 합성 주소에 계속 연결하면 코어가 도메인을 복원하지 못할 수 있습니다. 시작 직후에는 정상인데 설정을 전환한 뒤 일부 앱만 실패하는 현상으로 나타날 수 있습니다.

내부 도메인은 TUN에서 제외되거나 로컬 네트워크 주소에 의존할 수 있으므로 보통 실제 DNS 조회 결과가 필요합니다. 이런 도메인에는 명확한 실제 DNS 경로를 설정하고 후속 연결도 내부 네트워크를 통해 처리되는지 확인하세요. 내부 IP만 직접 연결로 설정하고 내부 도메인은 합성 주소를 반환하게 두지 마세요. 일부 앱은 DNS 결과를 직접 확인하거나 조회 주소를 연결 외의 용도로 사용하므로 예외 처리가 필요할 수 있습니다.

FakeDNS가 반환하는 주소는 내부 매핑용이므로 ‘먼저 조회한 뒤 실제 IP로 분류’하는 일반적인 판단이 그대로 적용되지 않을 수 있습니다. 라우팅 규칙을 검사하기 전에 도메인 복원이 이루어지는지, 현재 구현에서 합성 주소·도메인·IP 규칙을 어떤 순서로 처리하는지 먼저 확인하세요. 특히 직접 연결, 내부 주소, 실제 주소가 필요한 규칙은 같은 IP 목록만으로 결과를 추정할 수 없습니다. 설정 목표가 주로 도메인 분할이라면 명확한 도메인 규칙부터 검증하고 범위를 넓혀 가세요.

단계별 활성화 및 종료

테스트할 때는 일반 DNS와 TUN이 정상인 기준 상태를 유지한 채 FakeDNS를 켜세요. 도메인 조회 결과가 풀에 포함된 주소인지 확인한 다음 같은 앱의 연결에서 도메인이 복원되는지 살펴보세요. 두 단계가 모두 성공한 뒤에 분할 라우팅과 LAN을 확인하세요. 조회가 FakeDNS에 도달하지 않으면 DNS 진입점을 점검하고, 합성 주소를 받았는데 연결이 실패하면 상위 리졸버를 계속 바꾸지 말고 연결 인계와 진입점의 매핑 복구를 확인하세요.

FakeDNS를 끌 때는 캐시도 처리해야 합니다. 먼저 실제 DNS 경로를 복원한 뒤 합성 주소를 보유한 앱을 재시작하고, 필요하면 시스템 방식으로 DNS 캐시를 정리하세요. 기존 DNS 결과를 남긴 채 트래픽 인계 진입점만 끄면 일시적으로 접속이 실패할 수 있습니다. 문제를 해결하는 동안 합성 주소를 정적 도메인 매핑, 서버 주소, 장기 규칙에 넣지 마세요. 해당 매핑 환경 안에서만 의미가 있습니다. 실제 DNS 조회가 복구된 뒤 롤백 완료 여부를 판단하세요.

다중 구독 관리와 업데이트 분리

다중 구독 관리의 목적은 모든 항목을 하나의 긴 목록으로 합치는 것이 아니라 출처, 업데이트, 사용 상태를 추적 가능하게 유지하는 것입니다. 서로 다른 출처가 비슷한 메모를 사용하거나 같은 서버에 서로 다른 매개변수를 반환할 수 있습니다. 그룹은 업데이트 경계, 현재 활성 서버는 연결 경계, 라우팅은 트래픽 경계로 관리해야 합니다. 각 경계를 따로 관리하면 특정 출처에 문제가 생겨도 다른 그룹과 현재 사용 가능한 연결을 유지할 수 있어 전체 설정을 다시 만들 필요가 없습니다.

출처별 업데이트 책임 분리

독립된 출처마다 그룹을 하나씩 만들고 여러 주소를 한 주소 입력란에 합치지 않는 것이 좋습니다. 메모에는 용도를 적되 접근 매개변수나 신원 정보는 넣지 마세요. 그룹별로 수동 업데이트를 먼저 진행해 가져오기 형식, 필터 조건, 서버 변경을 확인한 뒤 자동 업데이트를 설정하세요. 두 그룹이 같은 출처에서 왔지만 필터 범위만 다르다면 같은 서비스에 중복 요청을 보낸다는 점을 고려해야 합니다. 불필요하게 반복되는 업데이트는 적절히 합치세요.

업데이트 주기는 출처의 변경 빈도와 실제 사용 요구에 맞추세요. 자주 업데이트한다고 더 좋은 것은 아닙니다. 업데이트를 자주 하면 요청 횟수가 늘고 테스트 중 서버 항목이 바뀔 수 있습니다. 연결 상태를 비교해야 한다면 관련 그룹의 자동 업데이트를 잠시 중지해 설정을 고정한 뒤 테스트하세요. 업데이트 후에는 예상한 서버가 여전히 선택되어 있는지 확인해야 합니다. 기존 항목이 삭제되거나 매개변수가 새로 생성된 경우 특히 주의하세요. 클라이언트가 선택 항목을 기억한다고 해서 확인 절차를 대신할 수는 없습니다.

특정 그룹에서 업데이트 문제가 발생하면 그 그룹만 점검하세요. 주소와 인증을 확인하고, 직접 연결과 프록시를 통한 결과를 비교한 다음 반환 형식을 확인합니다. 다른 그룹의 업데이트가 정상이라는 사실은 해당 출처에 연결할 수 있다는 뜻일 뿐, 실패한 출처의 주소에 문제가 없다는 뜻은 아닙니다. 모든 그룹에서 동시에 실패한다면 공통 네트워크, DNS, 프록시 진입점의 변화일 가능성이 더 큽니다. 문제 범위를 이렇게 좁히면 모든 출처를 다시 가져오는 불필요한 작업을 줄일 수 있습니다.

중복 항목과 측정 결과

중복 항목을 메모만 보고 정리해서는 안 됩니다. 메모가 같아도 포트, 프로토콜, 전송 방식, 암호화 매개변수가 다를 수 있고, 메모가 달라도 같은 연결을 가리킬 수 있습니다. 삭제 전에 주요 연결 필드를 비교하고 출처 관계를 보존하세요. 안내나 도움 요청에서는 차이를 설명할 수 있지만 전체 연결 매개변수를 공개해서는 안 됩니다. 장기간 사용할 항목을 남길 때는 출처와 용도를 기록해 다음 업데이트 뒤에도 식별할 수 있도록 하세요.

지연 시간 테스트, 실제 요청, 대역폭 테스트는 서로 다른 항목을 측정하므로 한 번의 순위를 고정적인 선택 기준으로 삼으면 안 됩니다. 테스트 결과는 로컬 네트워크, 테스트 주소, 동시 연결 수, 서버 부하에도 영향을 받습니다. 여러 그룹을 비교할 때 같은 방식과 대상, 비슷한 시간대에 테스트하고 이미 정상인 항목을 기준으로 남겨 두세요. 자세한 원리는 Tcping, 실제 연결 지연 시간, 다운로드 속도 측정의 차이를 참고하세요.

지역 이름만 보고 서버를 선택하지 마세요. 지역 표시는 대개 출처에서 제공한 메모이며 진입 위치, 출구 위치, 실제 회선을 모두 설명하지 않을 수 있습니다. 배율, 프로토콜 호환성, 용도 제한도 선택에 영향을 줍니다. 테스트 지연 시간이 낮아도 지속적인 전송이나 특정 앱에 적합하지 않을 수 있습니다. 계속 바뀌는 전체 순위를 보관하는 것보다 ‘일반 용도, 특정 용도, 예비용’처럼 후보를 소수로 관리하는 편이 유지보수하기 쉽습니다.

백업 및 출처 종료

설정 백업에는 구독 주소, 서버 식별 매개변수, 사용자 지정 아웃바운드, 라우팅이 함께 들어갈 수 있습니다. 백업은 통제된 위치에 보관하고 일반적인 스크린샷 첨부 파일로 공유하지 마세요. 복원할 때는 먼저 클라이언트와 코어의 호환성을 확인한 뒤 그룹별로 가져오세요. 오래된 백업에서 만료된 주소가 새 업데이트 출처로 자동 등록되어서는 안 됩니다. 복원에 성공했다는 것은 설정을 읽었다는 뜻일 뿐이므로 현재 네트워크에서 연결, DNS, 라우팅 결과를 다시 검증해야 합니다.

더 이상 사용하지 않는 출처가 있다면 먼저 활성 서버를 다른 항목으로 바꾸고 해당 그룹의 업데이트를 중지한 뒤 관련 라우팅이나 사용자 지정 아웃바운드가 해당 항목을 참조하는지 확인하세요. 의존성이 없다면 그룹을 삭제합니다. 로컬 그룹을 삭제해도 출처 측 인증이나 서비스가 취소되는 것은 아니므로 해당 출처의 관리 절차를 따라야 합니다. 잠시 사용하지 않는 것이라면 그룹을 보존하고 명확하게 비활성화하는 편이 주소를 여러 임시 항목에 복사하는 것보다 복구하기 쉽고 민감 정보의 저장 범위도 관리하기 좋습니다.

사용자 지정 아웃바운드와 코어의 경계

사용자 지정 아웃바운드는 요청이 코어를 벗어나는 방식을 정의합니다. 일반적으로 직접 연결, 차단, 기존 프록시 서비스를 통한 전달 등의 역할을 담당합니다. 라우팅은 태그로 아웃바운드를 참조합니다. 태그는 내부 식별자이지 서버 메모나 구독 그룹 이름이 아닙니다. 먼저 아웃바운드의 역할을 명확히 설계한 뒤 일치 규칙을 작성하면 태그 오타, 기본 경로 변경, 클라이언트 생성 설정이 로컬 편집을 덮어쓰는 문제를 줄일 수 있습니다. 일반적인 사용은 v2rayN 그래픽 설정을 우선 이용하세요.

태그와 기본 경로 정의

다음은 Xray의 직접 연결 및 차단 아웃바운드 조각이며 프록시 서버는 포함되어 있지 않습니다. freedom과 blackhole 구조를 이해하는 데 사용할 수 있지만 현재 아웃바운드 목록 전체를 덮어쓰면 안 됩니다. 이 두 아웃바운드만 남기면 일치하지 않는 연결은 보통 첫 번째 직접 연결 아웃바운드로 전달됩니다. 기본 프록시를 사용하려면 클라이언트가 생성한 프록시 아웃바운드를 유지하고 순서와 대체 라우트를 확인하세요. 태그만 proxy로 바꾸면 해결되는 것이 아닙니다.

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

태그는 짧고 역할이 안정적이어야 합니다. 예를 들어 직접 연결, 차단, 특정 프록시 진입점에 서로 다른 식별자를 사용하세요. 태그를 중복 사용하거나 파일마다 같은 태그에 다른 의미를 부여하지 마세요. 라우팅에서 참조하는 이름은 아웃바운드 태그와 정확히 일치해야 합니다. 아웃바운드를 바꿀 때는 관련 규칙과 다른 참조 항목을 검색하세요. 특히 DNS 조회와 특정 앱 규칙을 확인해야 합니다. 참조되지 않는 아웃바운드가 존재한다고 해서 요청이 자동으로 그 아웃바운드를 사용하는 것은 아닙니다.

차단 아웃바운드는 보내지 않아도 되는 요청이 명확할 때 적합하지만 모든 연결 실패를 처리하는 수단으로 사용해서는 안 됩니다. 알 수 없는 도메인을 전부 차단하면 앱에서 필요한 인증, 리소스, 업데이트 요청까지 실패할 수 있습니다. 직접 연결 아웃바운드는 현재 기기의 네트워크와 DNS 기능에 의존하므로 모든 대상에 접속할 수 있다는 뜻은 아닙니다. 아웃바운드 이름을 ‘빠름’이나 ‘안전’으로 정하는 것보다 역할 범위와 검증 대상을 정하는 편이 실용적입니다.

로컬 전달과 프록시 체인

다음은 로컬 SOCKS 서비스로 전달하는 아웃바운드 설정 조각입니다. 별도의 서비스가 127.0.0.1:10808에서 수신 중이라고 가정하며, 이 예시가 서비스를 생성하지는 않습니다. 포트가 같은 코어의 진입점이고 그 진입점이 다시 이 아웃바운드로 연결된다면 순환이 발생할 수 있습니다. 수신 프로세스, 진입점의 목적지, 최종 출구를 반드시 확인하세요. 로컬 포트에 연결할 수 있다고 해서 전달 경로가 올바르게 완성된 것은 아닙니다.

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

프록시 체인은 여러 처리 단계를 연결하므로 연결, DNS 조회, 장애에 대한 의존성이 늘어납니다. 설계할 때는 각 홉의 진입점과 출구를 그린 다음 대상 도메인을 어느 단계에서 조회할지, UDP 전달이 가능한지, 단계 하나가 중단되면 어떻게 되는지 확인하세요. 모든 아웃바운드가 같은 체인 설정 필드를 지원하는 것은 아닙니다. 체인 전달이 필요하다면 현재 코어의 설정 구조를 따르고 다른 구현의 필드를 기존 객체에 그대로 붙여 넣지 마세요.

수신 주소도 보안 경계의 일부입니다. 로컬 기기에서만 사용할 진입점은 보통 루프백 주소로 제한합니다. 모든 인터페이스에서 수신하면 접근 범위가 넓어지므로 인증과 방화벽을 함께 설정해야 합니다. 다른 기기에서 접속하게 하려고 인증되지 않은 프록시 진입점을 그대로 공개하지 마세요. 로컬 SOCKS 설정에 맞는 서비스도 포트 충돌, 시작 순서, 종료 동작을 명확히 해야 합니다. 부팅 후 하위 코어만 실행되고 상위 서비스가 없는 상황을 방지할 수 있습니다.

클라이언트 생성 설정과 코어 호환성

v2rayN은 화면에서 선택한 옵션을 바탕으로 실행 설정을 생성합니다. 임시 생성 파일을 직접 수정하면 서버 전환, 설정 저장, 재시작 시 덮어써질 수 있습니다. 클라이언트가 제공하는 사용자 지정 설정이나 확장 기능을 우선 사용하고 ‘조각 병합’인지 ‘전체 교체’인지 확인하세요. 두 방식의 책임은 다릅니다. 전체 교체 방식은 보통 진입점, 아웃바운드, 라우팅, DNS를 직접 제공해야 합니다. 병합 방식에서는 태그 충돌과 덮어쓰기 순서를 이해해야 합니다.

Xray와 V2Fly는 기본 개념 일부를 공유하지만 프로토콜 기능과 확장 필드가 완전히 같지는 않습니다. v2rayNG는 주로 Xray 생태계의 설정을 참고하며, v2flyNG는 V2Fly 지원 여부를 기준으로 확인해야 합니다. 화면에서 프로토콜 이름을 인식한다고 해서 모든 전송 방식 조합을 사용할 수 있다는 뜻은 아닙니다. 코어 차이는 클라이언트 및 코어 비교와 Xray와 V2Fly 차이 안내를 참고하세요.

코어를 전환하기 전에 기준 설정을 저장하고 프로토콜, 전송 방식, 보안 매개변수, 라우팅, DNS 필드를 하나씩 비교하세요. 테스트할 때는 연결 하나만 먼저 확인한 다음 사용자 지정 아웃바운드와 복잡한 규칙을 복원하세요. 시작에 실패하면 로그를 보고 필드를 수정하세요. 알 수 없는 옵션을 모두 삭제하는 방식으로 처리하지 마세요. 시작 성공은 문법과 일부 초기화가 통과했다는 뜻일 뿐입니다. 각 아웃바운드와 라우팅이 예상대로 작동하는지는 실제 요청으로 확인해야 합니다.

설정 검증 및 롤백 절차

고급 설정을 마쳤다면 웹페이지 하나가 열리는지 보는 데 그치지 말고 정해진 검증 절차를 따르세요. 최소한 시작, 프록시 연결, 도메인 조회, 규칙 일치, 특수 진입점, 종료 후 복구를 각각 확인해야 합니다. 항목마다 명확한 테스트 대상을 정하고 변경 내용과 관찰 결과를 기록하세요. 문제가 생기면 최근에 수정한 모듈부터 롤백하고 나머지 정상 설정은 보존하세요. 정상 설정을 실수로 삭제하지 않으면서 다음 변경 때 반복 가능한 테스트 조건도 마련할 수 있습니다.

시작부터 연결까지 단계별 확인

첫 번째 단계는 코어가 시작되는지 확인하는 것입니다. 처음으로 나타나는 명확한 오류와 주변 필드 안내를 살펴보고 JSON 문법, 알 수 없는 필드, 리소스 누락, 포트 점유를 구분하세요. JSON에는 주석이나 마지막 쉼표를 넣을 수 없습니다. 부분 설정을 여러 개의 최상위 객체로 바로 이어 붙여서도 안 됩니다. 클라이언트 화면에 ‘실행 중’으로 표시되어도 코어가 곧바로 종료되지는 않았는지 확인하세요. 오류가 반복되면 자동 재시작이나 반복 실행을 먼저 멈춘 뒤 전체 오류를 한 번 읽으세요.

두 번째 단계는 진입점이 요청을 받는지 확인하는 것입니다. 앱에서 사용하는 프록시 주소와 포트가 현재 수신 설정과 일치하는지, 시스템 프록시 상태도 실제 진입점과 맞는지 확인하세요. 진입점이 연결을 받은 다음 서버 연결과 프로토콜 핸드셰이크를 점검합니다. 시간 초과, 연결 거부, 인증 실패는 서로 다른 문제이므로 모든 문제에 ‘DNS 바꾸기’ 하나로 대응하지 마세요. 서버 매개변수는 인증된 설정에서 가져오므로 서버 주소만 비교하지 말고 필요한 필드를 모두 확인하세요.

세 번째 단계는 DNS 조회와 라우팅입니다. 직접 연결되어야 하는 대상 하나와 프록시를 사용해야 하는 대상 하나를 선택하고 로그에서 대상 정보와 아웃바운드 태그를 비교하세요. 새 규칙을 테스트할 때는 기존 연결을 재사용하지 말고 연결을 다시 만드세요. 로그에 IP만 나타나면 진입점에서 도메인 정보가 보존되는지, 스니핑이 작동하는지, FakeDNS가 도메인을 복원했는지 먼저 확인하세요. 도메인 정보 누락과 규칙 우선순위 오류 모두 규칙 불일치를 일으킬 수 있지만 해결 방법은 다릅니다.

범위를 제한해 재현 가능한 테스트 구성 만들기

테스트 구성은 크지 않아도 되지만 설정 목표는 포함해야 합니다. 일반 웹페이지, 직접 연결해야 하는 내부 서비스, 프록시가 필요한 요청 하나, 실제 사용하는 특수 앱을 준비하세요. 테스트 당시 TUN과 FakeDNS를 켰는지, 어떤 서버를 선택했는지, 네트워크 환경은 어땠는지 기록하세요. 모바일 네트워크와 유선 네트워크 결과를 한데 묶어 비교하면 안 됩니다. 특정 네트워크에서만 문제가 생긴다면 그 차이를 기록하고 네트워크 측 DNS, 출구, 방화벽 조건을 먼저 확인하세요.

속도 측정은 참고 자료가 될 수 있지만 기능 테스트를 대신하지는 않습니다. 핸드셰이크 지연 시간이 낮아도 앱 인증이 성공한다는 뜻은 아니고, 다운로드 속도가 높아도 라우팅과 DNS가 설계에 맞는다는 뜻은 아닙니다. 테스트에 실패하면 필터링, 라우팅, TUN 등 모듈을 복원하기 전에 가장 단순한 설정으로 실제 요청을 한 번 완료하세요. 서버와 코어를 동시에 바꾼 뒤 결과를 비교하지 마세요. 어떤 변경이 복구를 유도했는지 알 수 없습니다. 한 번에 변경을 적게 할수록 장기간 유지할 해결 방법을 찾기 쉽습니다.

문제를 해결하는 동안에만 필요한 수준으로 로그 레벨을 높이고, 원인을 찾은 뒤에는 평소 설정으로 되돌리세요. 로그에 대상 도메인, 서버 주소, 민감한 매개변수가 포함될 수 있으므로 공유 전에 하나씩 확인해야 합니다. 오류 유형, 필드 이름, 필요한 맥락, 재현 절차만 남기면 충분합니다. 전체 구독, 전체 설정, 계속 실행 중인 모든 로그를 공개하지 마세요. 도움을 요청할 때는 실패 스크린샷만 붙이지 말고 ‘무엇을 바꿨는지, 무엇을 예상했는지, 실제로 무엇이 발생했는지’를 설명하세요.

단계별 롤백과 유지보수 기록

롤백은 변경한 순서의 역순으로 진행하세요. 마지막에 추가한 규칙이나 아웃바운드를 먼저 복원하고, 그다음 DNS를 복원한 뒤 TUN과 FakeDNS 같은 진입점 변경을 되돌립니다. 마지막 변경이 진입점이었다면 먼저 해당 진입점을 끄고 제어 경로를 복구하세요. 롤백할 때마다 다시 테스트해 여러 모듈을 한꺼번에 되돌린 뒤 근거를 잃지 않도록 합니다. 기준 상태가 복구되면 작업용 설정을 새로 복사해 다음 조정을 진행하세요. 원인을 설명할 수 없는 혼합 상태에 규칙을 계속 덧붙이지 마세요.

유지보수 기록에는 날짜, 모듈, 변경 이유, 검증 결과, 롤백 위치만 적고 인증 정보는 저장하지 않아도 됩니다. 구독 자동 업데이트, 네트워크 전환, 코어 전환은 다시 검증해야 하는 조건입니다. 출처를 업데이트한 뒤에는 활성 서버를, 네트워크를 바꾼 뒤에는 내부 DNS와 라우팅을, 코어를 바꾼 뒤에는 필드 호환성을 중점적으로 확인하세요. 변경 범위에 맞춰 재검증하면 매번 설정을 처음부터 다시 만드는 것보다 수월하고 실제 장애가 발생한 경계도 파악하기 쉽습니다.

일상적인 연결 복구가 우선이라면 구독 가져오기 및 연결 기본 절차로 돌아가면 됩니다. 모든 고급 기능을 한 번에 설정할 필요는 없습니다. 설치 환경을 조정해야 한다면 플랫폼별 다운로드를 이용하고, 오류별 안내는 도움말 센터에서 확인하세요. 이 안내서의 각 장은 필요한 부분만 적용하면 됩니다. 옵션을 계속 추가하기보다 명확하고 검증 가능한 설정을 소수로 유지하는 편이 장기적인 관리에 적합합니다.