V2Ray 고급 설정 가이드

구독 그룹 및 서버 필터링

구독 주소와 연결 설정을 분리해 관리하기

v2rayN에서 ‘구독 그룹 설정’을 열고 먼저 별도의 그룹을 만든 다음 구독 주소를 입력하세요. 그룹에는 업데이트 출처, 메모, 필터 조건이 저장되고 서버 항목에는 가져온 연결 프로토콜 매개변수가 저장됩니다. 그룹 메모를 바꿔도 원격 연결 정보는 변경되지 않으며, 구독을 업데이트해도 현재 서버가 자동으로 바뀌지는 않습니다. 업데이트가 끝나면 메인 창에서 현재 선택된 항목을 확인하세요.

그룹 이름에는 ‘일상 사용’이나 ‘호환성 테스트’처럼 용도와 출처를 드러내는 표현을 사용하세요. 구독 주소를 메모, 스크린샷 또는 공유 문서에 그대로 적지 마세요. 주소의 경로와 쿼리 매개변수는 접근 권한을 부여할 수 있습니다. 문제를 점검할 때는 주소 유형, 응답 상태, 오류 문구만 기록하고 구체적인 내용은 숨기세요. 주소를 복사할 때는 기존 인코딩을 유지하고 중복처럼 보이는 매개변수도 임의로 삭제하지 마세요.

처음 업데이트할 때는 필터 조건을 끄고 서버 목록을 가져올 수 있는지 확인한 뒤 제한 조건을 하나씩 추가하세요. ‘주소 응답이 비어 있음’과 ‘응답은 있지만 필터에서 제외됨’을 구분해야 합니다. 전자는 구독 유효성, 네트워크 연결, 응답 형식을 확인해야 하고 후자는 필터 표현식을 확인해야 합니다. 반복 새로고침으로 잘못된 필터 조건을 고칠 수는 없으며, 오히려 실제 응답 정보를 놓칠 수 있습니다.

필드와 일치 방식에 따라 범위 좁히기

서버 필터를 사용하기 전에 설정 설명을 확인하세요. 서버 메모, 프로토콜 유형 또는 다른 필드 중 무엇을 대상으로 하는지, 일반 텍스트·부분 일치·정규식 중 어떤 방식인지 확인해야 합니다. 화면이 다르면 규칙도 같다고 가정할 수 없습니다. 해당 필드에서 정규식을 지원한다고 명시된 경우 아래 표현식으로 메모에 있는 테스트 또는 예비 표시를 찾을 수 있습니다. 이 표현식은 일치 조건일 뿐이며, 해당 항목을 남길지는 필터 설정의 동작에 따라 달라집니다.

(테스트|예비)

처음부터 복잡한 제외 조건을 조합하지 마세요. 먼저 메모가 확인된 항목 하나로 테스트하고, 일치하지 않아야 하는 다른 항목을 확인한 뒤, 메모가 비어 있는 경우도 검사하세요. 정규식에서 괄호, 세로줄, 마침표는 특수한 의미가 있습니다. 마침표 문자 자체를 찾으려면 역슬래시와 마침표를 함께 써야 합니다. 대소문자 구분 여부는 해당 필드의 구현을 기준으로 판단하세요. 화면에 표시된 문자 모양만으로 추측해서는 안 됩니다.

구독 출처마다 이름 지정 방식이 다르면 모든 이름을 하나의 표현식에 넣기보다 그룹별로 필터를 설정하세요. 원격에서 메모 형식이 바뀌면 기존 조건이 갑자기 모든 항목을 제외할 수 있습니다. 업데이트 전에 남아 있어야 할 이름의 특징을 기록하고, 업데이트 후에도 해당 특징이 있는지 확인하세요. 목록 개수 변화만으로 서비스 이상 여부를 판단하지 마세요. 구독 출처에서 제공하는 내용 자체가 바뀌었을 수도 있습니다.

업데이트 덮어쓰기와 연결 매개변수 차이 처리

구독 항목은 일반적으로 원격 데이터로 다시 생성됩니다. 전송 매개변수를 장기간 수정해야 한다면 클라이언트에 별도 저장 또는 수동 항목으로 복사하는 기능이 있는지 먼저 확인하세요. 복사한 항목은 별도의 그룹에 넣고 구독 업데이트가 더 이상 자동으로 반영되지 않는다는 점을 분명히 해 두세요. 구독 항목을 직접 수정한 뒤 다음 새로고침에도 변경 사항이 유지될 것이라고 단정하지 마세요. 먼저 업데이트를 한 번 제어된 방식으로 수행해 어떤 필드가 덮어써지는지 확인하세요.

‘가져오기는 성공했지만 연결되지 않음’ 문제가 발생하면 프로토콜, 서버 주소, 포트, 전송 방식, TLS 관련 필드를 확인하세요. 가져오기에 성공했다는 것은 클라이언트가 형식을 인식했다는 뜻일 뿐, 현재 코어가 모든 기능을 지원한다는 뜻은 아닙니다. v2rayNG와 v2flyNG는 서로 다른 코어 계열을 사용하므로 겉모습이 비슷하다는 이유로 설정을 서로 바꿔 사용할 수 없습니다. 먼저 필요한 프로토콜을 확인한 뒤 사용할 클라이언트를 선택하세요.

구독 업데이트에 실패하면 현재 사용할 수 있는 설정을 먼저 저장하고 모든 그룹을 바로 비우지 마세요. 주소의 완전성, 시스템 시간, 인증서 오류, 업데이트 요청의 프록시 경유 여부를 순서대로 확인하세요. 자세한 항목은 v2rayN 구독 업데이트 실패 문제 해결을 참고하세요. 출처 문제를 바로잡은 다음 필터 조건을 다시 적용해 주소와 필터 로직을 동시에 바꾸지 않도록 하세요.

마지막으로 최소한의 검증을 수행하세요. 그룹 하나를 업데이트하고 용도가 확인된 항목 하나를 선택해 코어를 시작한 뒤 로그에 설정 파싱 오류가 없는지 확인합니다. 검증이 끝난 다음 자동 업데이트를 활성화하세요. 이렇게 하면 구독 형식, 필터 조건, 연결 매개변수를 서로 다른 문제로 분리할 수 있어 한 번의 일괄 작업으로 사용 가능한 기준 설정을 잃지 않습니다.

DNS 설정 최적화

실제 DNS 조회 경로부터 정리하기

DNS는 앱, 운영체제, 클라이언트, 원격 출구의 각 위치에서 확인하세요. 브라우저가 자체 보안 DNS를 사용할 수 있고, 시스템이 로컬 네트워크의 리졸버를 사용할 수도 있으며, 코어가 별도의 캐시를 유지하거나 프록시 서버가 최종 대상 도메인을 조회할 수도 있습니다. ‘DNS 설정’을 변경해도 해당 설정이 처리하는 쿼리만 영향을 받습니다. 모든 앱이 새 서버를 즉시 사용한다고 가정하지 마세요.

먼저 앱이 프록시에 도메인과 주소 중 무엇을 전달하는지 확인하세요. 원격 조회를 지원하는 프록시 방식에서는 앱이 도메인을 프록시에 전달할 수 있습니다. 앱이 먼저 직접 조회한 뒤 주소를 클라이언트에 전달하면 도메인 기반 분기에 필요한 원래 정보가 사라질 수 있습니다. 이 경우 앱의 프록시 옵션이나 트래픽 처리 방식을 확인해야 하며 DNS 도메인 규칙을 하나 추가하는 것만으로 전체 맥락을 복구할 수는 없습니다.

중요한 조회 경로 두 가지를 구분하세요. 프록시 서버 자체 주소의 조회와 서비스 대상의 조회입니다. 첫 번째는 프록시 연결을 수립하기 전에 이루어지므로 독립적으로 작동하는 경로가 있어야 합니다. 유일한 부트스트랩 리졸버를 ‘프록시 연결 이후에만 접근 가능’하게 설정하면 시작 과정에서 순환이 발생합니다. 도메인 형식의 암호화 DNS 서비스를 설정할 때는 서비스 이름의 주소를 처음에 어떻게 조회하는지도 고려하세요.

용도에 따라 리졸버 지정하기

아래는 해당 필드를 지원하는 V2Fly 또는 Xray 설정에서 사용할 수 있는 내장 DNS 설정 조각입니다. 일반 쿼리는 공용 리졸버로 보내고 로컬 도메인은 시스템 리졸버에 전달합니다. 도메인 조건과 쿼리 정책을 설명하기 위한 예시이며, 공용 리졸버가 모든 네트워크에서 접속 가능하다는 뜻은 아닙니다. 실제로 사용하기 전에 네트워크 요구 사항에 맞게 바꾸고 클라이언트가 이 설정을 덮어쓰는지 확인하세요.

{
  "dns": {
    "queryStrategy": "UseIP",
    "servers": [
      "1.1.1.1",
      {
        "address": "localhost",
        "domains": ["domain:localhost"]
      }
    ]
  }
}

내부 네트워크 서비스는 로컬 DNS의 사설 레코드에 의존하는 경우가 많습니다. 모든 쿼리를 공용 리졸버로 보내면 해당 레코드가 없거나 현재 네트워크에 적합하지 않은 주소를 반환할 수 있습니다. 기업 내부 도메인, 라우터 관리 이름, 자체 호스팅 서비스에는 명확한 로컬 조회 경로를 유지하세요. 한 단어로 된 이름을 모두 공용 도메인으로 취급하지 말고, 내부 이름 하나를 해결하려고 전체 DNS 분기를 끄지도 마세요.

리졸버의 전송 방식과 쿼리가 실제로 이동하는 경로는 서로 다른 문제입니다. 암호화 DNS를 사용하면 해당 전송 경로를 보호할 수 있지만 프록시를 통과하는지는 코어 구현, 아웃바운드 규칙, 클라이언트 설정 생성 방식에 따라 달라집니다. 일부 로컬 조회 모드는 일반 라우팅 처리를 우회할 수 있습니다. 동작을 확인할 때는 실행 설정과 연결 로그를 살펴보세요. 주소 문자열에 암호화 프로토콜 이름이 있는지만으로 경로를 판단하지 마세요.

‘기대 주소’와 같은 조건은 반환 결과가 규칙의 기대에 맞는지 판단하는 용도이지 속도를 높이는 범용 설정이 아닙니다. 활성화한 뒤 정상 응답이 거부되면 대체 조회가 발생해 오히려 문제를 찾기 어려워질 수 있습니다. 기본 조회가 성공하는지 먼저 확인하고 결과 조건을 추가하세요. 조건을 하나 더할 때마다 결과를 비교할 수 있는 도메인 하나와 예상 조회 범위를 기록해 두세요.

주소 계열과 캐시를 각각 확인하기

IPv4와 IPv6를 함께 지원하는 네트워크에서는 조회와 연결을 각각 확인해야 합니다. IPv6 주소를 얻었다고 현재 출구에서 IPv6 경로를 사용할 수 있다는 뜻은 아닙니다. 주소를 선택한 뒤 연결에 실패하는 로그가 나타나면 시스템 라우팅과 출구 지원을 확인한 다음 조회 정책을 조정하세요. IPv6 설정을 모두 삭제하면 증상이 일시적으로 바뀔 수는 있지만 DNS 서비스가 원래 문제였다는 증거가 되지는 않습니다.

리졸버를 변경한 뒤에도 브라우저, 시스템, 코어에 각자 캐시가 남아 있을 수 있습니다. 테스트할 때 기존 연결을 끊고 테스트 앱을 다시 시작한 뒤 필요하면 관련 캐시를 갱신하세요. 서버와 조회 정책을 동시에 바꾸지 마세요. 결과 변화의 원인을 알 수 없습니다. 시스템 조회 도구는 시스템 DNS 경로를 검증하지만 코어 내장 DNS를 통과하지 않을 수 있으므로 시스템 도구와 브라우저 결과가 다른 것이 설정 미적용을 뜻하지는 않습니다.

문제를 찾을 때는 비교용으로 간단한 조회 경로 하나를 유지하세요. 복잡한 대체 조회와 결과 필터를 먼저 끄고 기본 쿼리가 완료되는지 확인한 뒤 도메인 분류, 주소 계열 선호, 암호화 전송을 차례로 복구하세요. 로컬 이름은 정상인데 외부 이름이 실패하면 외부 리졸버에 연결할 수 있는지 확인하세요. 쿼리는 완료됐지만 대상에 연결할 수 없다면 조회 서버를 계속 추가하지 말고 라우팅 장으로 돌아가 아웃바운드를 확인하세요.

마지막으로 DNS 로그의 개인정보 영향을 확인하세요. 디버그 로그에는 방문한 전체 도메인이 포함될 수 있으며 장기간 보관하면 상세한 활동 기록이 됩니다. 검증이 끝나면 평소 로그 수준으로 되돌리고 오류 정보를 공유할 때 내부 이름과 구독 관련 정보를 숨기세요. DNS 최적화의 목표는 경로를 명확하게 하고 결과를 설명할 수 있게 하는 것이지 업스트림을 최대한 많이 설정하는 것이 아닙니다.

FakeDNS

가상 주소와 도메인 매핑 이해하기

FakeDNS는 대상의 실제 주소를 반환하는 대신 전용 주소 풀에서 가상 주소를 할당하고 도메인과 주소의 대응 관계를 저장합니다. 앱이 해당 주소에 연결하면 트래픽 처리 구성 요소가 매핑을 통해 원래 도메인을 복원한 뒤 라우팅과 아웃바운드 처리를 수행합니다. 주로 주소 형태로 전달되는 트래픽에서 도메인을 식별하는 데 사용되며, 전체 DNS 경로를 단독으로 대체하는 공용 조회 서비스는 아닙니다.

설정이 제대로 작동하려면 전체 경로가 이어져야 합니다. 쿼리가 FakeDNS로 들어오고, 반환된 가상 주소가 동일한 트래픽 처리 경로로 전달되며, 매핑이 유지되고, 인바운드가 올바르게 도메인을 복원해야 합니다. 어느 한 단계라도 빠지면 ‘조회 결과는 있지만 사이트가 전혀 열리지 않음’ 문제가 생길 수 있습니다. 따라서 먼저 일반 DNS와 TUN을 검증한 뒤 FakeDNS를 추가하세요. 아직 안정적이지 않은 트래픽 처리 경로에 매핑을 더하지 마세요.

라우팅에서 가상 주소를 실제 네트워크로 직접 보내지 마세요. 가상 주소는 대상 서버의 주소가 아니며 일반 네트워크에서 접속할 수도 없습니다. 로그에서 주소 풀의 주소에 계속 연결을 시도한다면 해당 주소에 연결할 프록시 서버를 찾지 말고 매핑 복원과 트래픽 처리 범위를 확인하세요. 원래 도메인을 복원해야 이후 도메인 규칙과 원격 조회에 올바른 입력값이 전달됩니다.

코어 지원 여부와 인바운드 설정 맞추기

아래는 FakeDNS를 지원하는 Xray 설정의 요소로 주소 풀, DNS 서버, 대상 인바운드의 스니핑 설정에 각각 해당합니다. 세 요소는 실제 실행 설정의 올바른 위치에 병합해야 하며 임의로 추가할 수 있는 최상위 객체 세 개가 아닙니다. 클라이언트가 이미 해당 부분을 생성했다면 전용 설정을 사용해 중복 선언이나 다른 필수 옵션 덮어쓰기를 피하세요.

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

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

두 번째 부분은 인바운드 내부의 sniffing 객체이며 기존 설정을 대체하는 완전한 인바운드 객체가 아닙니다. 현재 인바운드에 HTTP 또는 TLS 스니핑도 필요하다면 기존 내용을 기계적으로 삭제하지 말고 코어 문서에 따라 목록을 병합하세요. 코어마다 가상 주소와 스니핑 구현이 다를 수 있습니다. v2flyNG에서 설정하기 전에 사용 중인 코어와 클라이언트가 해당 기능을 실제로 지원하는지 확인하세요.

예시 주소 풀은 가상 용도 대역이지만 로컬 기기나 현재 네트워크에서 이미 사용 중인지 확인해야 합니다. 테스트 환경, 다른 프록시 구성 요소, 네트워크 진단 도구가 같은 대역을 사용할 수 있습니다. 주소가 겹치면 라우팅 의미가 불분명해집니다. 비어 있는 것처럼 보이는 공인 대역을 임의로 선택하지 마세요. 클라이언트에서 주소 풀을 바꿀 수 있다면 해당 구현의 요구 사항을 따르고 라우팅 제외 항목도 함께 확인하세요.

주소 풀 용량은 보존할 수 있는 매핑 개수에 영향을 줄 뿐 접속 가능한 서버 수나 속도 설정을 뜻하지 않습니다. 용량이 너무 작으면 도메인이 많을 때 오래된 매핑이 더 빨리 제거될 수 있고, 무작정 늘리면 리소스 사용량이 증가할 수 있습니다. 먼저 구현에서 제공하는 적절한 기본값을 사용하세요. 로그와 재현 조건에서 매핑 제거가 원인으로 확인된 경우에만 조정하고 앱 하나가 느리게 열린다는 이유만으로 용량 부족이라고 단정하지 마세요.

캐시와 우회 앱 처리하기

FakeDNS를 활성화하거나 비활성화한 뒤에도 앱과 시스템에 이전 캐시가 남을 수 있습니다. 앱이 이전 가상 주소를 계속 사용하는데 해당 매핑이 재시작으로 사라지면 간헐적인 실패가 발생할 수 있습니다. 전환을 테스트할 때는 관련 앱 연결을 끊고 해당 조회 캐시를 지운 다음 새 요청을 보내세요. 브라우저가 이전 주소와 연결을 계속 재사용하도록 둔 채 코어만 재시작하지 마세요. 새 상태와 이전 상태가 뒤섞일 수 있습니다.

앱에 내장된 암호화 DNS는 예상한 쿼리 경로를 우회할 수 있으며 주소를 고정해 접속하면 도메인 조회 과정 자체가 없습니다. 이 두 유형의 트래픽에는 FakeDNS 매핑이 자동으로 적용되지 않습니다. 먼저 앱의 실제 동작을 확인한 뒤 앱 DNS, 프록시 방식 또는 트래픽 처리 범위를 조정할지 결정하세요. 다른 앱이 정상이라고 해서 문제 앱도 같은 조회 경로를 사용한다고 단정할 수 없습니다.

로컬 네트워크 이름과 실제 주소에 의존하는 앱에는 일반 DNS 경로를 유지하세요. 일부 서비스는 조회 결과를 트래픽이 처리되지 않는 다른 프로세스에 전달할 수 있으며, 해당 프로세스는 가상 주소를 사용하지 못할 수 있습니다. 이런 제한이 확인되면 가상 주소의 시스템 노출 범위를 넓히기보다 대상 이름에 명확한 조회 예외를 설정하세요. 프로세스 간 주소 전달 동작은 앱 구조에 따라 판단해야 합니다.

롤백할 때는 일반 조회를 먼저 복구하고 가상 매핑을 비활성화한 다음 오래된 캐시를 지우고 연결을 새로 만드세요. 롤백 후에도 가상 주소에 접속한다면 서버 설정을 계속 수정하지 말고 캐시 잔여분부터 처리하세요. FakeDNS의 목적은 라우팅에 필요한 도메인 정보를 보존하는 것입니다. 일반 도메인 인바운드로 요구 사항을 충족할 수 있다면 설정을 복잡하게 만들기 위해 FakeDNS를 활성화할 필요는 없습니다.

사용자 지정 아웃바운드

태그로 라우팅과 출구 연결하기

아웃바운드는 코어에서 연결이 빠져나가는 방식을 정의하고 라우팅은 태그를 통해 아웃바운드를 선택합니다. 태그는 설정 내부에서 참조하는 이름일 뿐 특별한 기능이 없습니다. 아웃바운드 이름을 direct로 지정해도 자동으로 직접 연결되지 않습니다. 실제 동작은 프로토콜과 설정으로 결정됩니다. 먼저 아웃바운드 객체를 확인하고 다음으로 라우팅 참조를 확인하세요. 이름의 철자가 일치하는 것은 설정에 필요한 조건이지 충분조건은 아닙니다.

그래픽 클라이언트는 보통 현재 선택한 서버에 맞는 프록시 아웃바운드와 직접 연결 및 차단 아웃바운드를 생성합니다. 사용자 지정 객체를 추가해야 한다면 클라이언트에서 제공하는 기능이 ‘조각 추가’, ‘전체 설정 교체’, 전용 사용자 설정 입력란 중 무엇인지 먼저 확인하세요. 부분 설정을 전체 설정 입력란에 넣으면 인바운드와 같은 필수 부분이 빠지고, 전체 설정을 추가 영역에 넣으면 정의가 중복될 수 있습니다.

아래는 네이티브 V2Ray 또는 Xray 설정에서 흔히 사용하는 직접 연결 및 차단 아웃바운드 조각으로 태그 구조를 이해하는 데 도움이 됩니다. 병합하기 전에 같은 태그가 이미 있는지 확인하세요. 이 예시에는 프록시 서버 인증 정보가 없고 완전한 클라이언트 설정도 포함되어 있지 않습니다. 전송 및 보안 매개변수가 누락되지 않도록 검증된 서버 항목에서 프록시 아웃바운드를 생성하세요.

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

단일 라우팅을 테스트한 뒤 조합 추가하기

아웃바운드를 추가한 뒤에는 범위가 작고 동작이 명확한 규칙 하나에서 먼저 참조하세요. 제어 가능한 테스트 대상을 선택해 코어가 시작되는지, 태그가 존재하는지, 규칙이 일치하는지 확인한 뒤 범위를 넓히세요. 기본 트래픽 전체를 바로 교체하지 마세요. 설정 오류가 있으면 모든 앱이 동시에 실패해 비교할 정보가 줄어들고 구독 업데이트나 도움말 페이지 연결도 끊길 수 있습니다.

직접 연결 아웃바운드도 DNS 조회와 시스템 네트워크의 영향을 받습니다. 방화벽을 우회하거나 특정 물리 인터페이스를 사용한다는 뜻은 아닙니다. 인터페이스를 바인딩하거나 발신 주소를 지정해야 한다면 현재 코어가 해당 옵션을 지원하는지, 시스템 권한이 있는지 확인하고 지정한 주소가 실제 기기에 할당되어 있는지 검증하세요. 다른 기기의 인터페이스 이름이나 주소를 복사하면 같은 경로를 얻는 대신 연결이 실패할 수 있습니다.

프록시 체인은 프록시 아웃바운드를 여러 개 배치하는 것만으로 만들어지지 않습니다. 명확한 전달 관계를 설정해야 연결이 여러 단계를 통과합니다. 일반 라우팅은 대개 여러 출구 중 하나를 선택할 뿐입니다. 체인을 구성하기 전에 각 구간이 개별적으로 작동하는지 확인하고 각 구간의 도메인 조회, 전송 프로토콜, 인증 요구 사항을 점검하세요. 어느 한 구간이 실패해도 전체 체인에 영향을 주므로 로그를 단계별로 살펴야 하며 마지막 시간 초과만 확인해서는 안 됩니다.

특히 UDP와 멀티플렉싱 동작을 확인하세요. 한 아웃바운드가 웹 연결을 처리한다고 해서 모든 데이터그램 트래픽에 적합한 것은 아닙니다. 특정 프로토콜이 멀티플렉싱을 지원한다고 해서 활성화하는 것이 모든 앱에 유리한 것도 아닙니다. 기본 설정을 먼저 유지하고 연결 설정 비용이나 호환성 문제를 명확히 확인한 경우에만 비교 테스트를 하세요. Mux를 무조건 속도를 높이는 스위치로 여기지 말고 서로 다른 코어의 멀티플렉싱 필드를 혼용하지 마세요.

기본 아웃바운드, 루프, 호환성 처리하기

명시적인 대체 규칙이 없으면 기본 아웃바운드는 객체 순서의 영향을 받을 수 있습니다. 새 객체를 삽입하면 기존 규칙을 바꾸지 않았더라도 일치하지 않는 트래픽의 경로가 달라질 수 있습니다. 수정 전에 기본 동작을 기록하고 수정 후에는 앞쪽 규칙과 일치하지 않는 대상을 별도로 테스트하세요. 기본 동작을 안정적으로 표현하려면 우연한 배치 순서에 의존하지 말고 현재 코어에서 지원하는 대체 방식을 사용하세요.

아웃바운드끼리 서로 참조해 루프를 만들지 않도록 하고 아웃바운드 연결이 다시 로컬 프록시 인바운드로 들어오지 않게 하세요. 전자는 코어 설정의 전달 관계에서 발생하고 후자는 시스템 프록시, TUN, 앱 프록시 설정 때문에 발생할 수 있습니다. 둘 다 연결 반복과 시간 초과로 나타날 수 있습니다. 문제를 점검할 때 실제 네트워크 출구까지 각 단계의 다음 홉을 그려 보세요. 출발점으로 돌아오는 화살표가 있다면 그 이유를 확인해야 합니다.

코어를 전환하기 전에 설정을 저장하고 프로토콜, 전송, 보안 옵션, 리소스 형식을 항목별로 확인하세요. V2Fly와 Xray는 일부 설정 개념을 공유하지만 모든 확장 기능이 호환되는 것은 아닙니다. v2rayNG와 v2flyNG도 이름이 비슷하다는 이유로 같은 실행 환경으로 간주할 수 없습니다. 코어에서 알 수 없는 필드를 보고하면 실제 지원 범위에 맞게 수정하세요. 오류 줄을 무작정 삭제한 뒤 원래 기능을 무시하지 마세요.

사용자 지정 설정을 관리할 때는 태그의 용도를 외부 기록에 적으세요. 엄격한 JSON에 주석을 넣으면 파싱이 실패할 수 있습니다. 저장할 때 괄호, 쉼표, 문자열의 따옴표, 중복 키를 확인하세요. 한 번에 논리 단위 하나만 수정하고 코어가 정상적으로 시작된 뒤 네트워크를 검증하세요. 문법 오류가 없다고 해서 출구에 연결할 수 있다는 뜻은 아닙니다. 다른 클라이언트를 선택해야 한다면 다운로드 페이지에서 플랫폼과 코어 용도를 확인하세요.

사용자 지정 아웃바운드를 되돌릴 때는 먼저 해당 아웃바운드를 참조하는 규칙을 삭제하거나 수정하고, 다음으로 객체를 삭제한 뒤 기본 경로를 확인하세요. 아웃바운드만 삭제하고 태그 참조를 남겨 두면 코어 시작이나 규칙 평가 단계에서 실패할 수 있습니다. 롤백이 끝나면 테스트 연결을 새로 만들고 클라이언트가 예상한 설정 생성 방식을 다시 사용하는지 확인하세요. 인터페이스 설정은 복원됐는데 실행 파일은 이전 상태로 남아 있을 수 있습니다.