V2Ray 고급 설정 가이드

01 / 설정 출처

구독 그룹과 서버 필터는 어떻게 설정하나요?

먼저 출처별로 그룹을 나눈 다음 용도에 따라 서버를 필터링하세요. 그룹은 ‘이 설정이 어디에서 왔고 누가 업데이트하는가’를 관리하고, 필터는 ‘현재 목록에 어떤 설정을 표시할 것인가’를 정합니다. 두 기능을 혼동하지 마세요. v2rayN의 구독 그룹에는 보통 구독 주소, 업데이트 옵션, 메모를 저장합니다. 서버 목록의 검색이나 필터는 표시 범위를 좁히는 용도입니다. 서버가 목록에 보이지 않는다고 반드시 삭제된 것은 아닙니다. 현재 그룹이나 검색 조건 때문에 숨겨졌을 수도 있습니다.

그룹을 만들기 전에 무엇을 기록해야 하나요?

주소를 입력하기 전에 그룹 이름, 출처 설명, 업데이트 방식을 먼저 기록하세요. 이름에는 출처와 용도가 드러나도록 ‘일상 연결’, ‘예비 테스트’처럼 지정하는 것이 좋습니다. 혼동하기 쉬운 연속된 숫자만 쓰지 마세요. 구독 주소에는 접근 자격 정보가 포함될 수 있으므로 클라이언트의 주소 입력란에만 붙여넣고, 메모나 스크린샷, 공개 문서에는 남기지 마세요. 처음 저장한 뒤 수동으로 한 번 업데이트해 예상한 프로토콜과 서버 이름이 목록에 표시되는지 확인한 다음 자동 업데이트를 설정하세요. 목록이 비어 있다고 그룹을 반복해서 삭제할 필요는 없습니다.

v2rayN에서는 구독 그룹 관련 메뉴에서 그룹을 편집하고 업데이트할 수 있습니다. v2rayNG와 v2flyNG에서는 구독 설정이나 해당 그룹 관리 메뉴를 찾으세요. ‘현재 그룹 업데이트’와 ‘모든 그룹 업데이트’의 명칭은 클라이언트마다 다를 수 있으니 실행 전에 적용 범위를 확인하세요. 가져온 뒤 서버가 하나만 보인다면 링크가 단일 공유 링크인지 구독 주소인지 먼저 구분하세요. 둘 다 긴 문자열처럼 보일 수 있지만 업데이트 동작은 다릅니다.

필터 표현식 때문에 결과가 사라지는 이유는 무엇인가요?

먼저 필터 기능의 동작 방식을 확인하세요. 일부 항목은 목록 검색에만 쓰이고, 일부는 구독 업데이트 시 항목을 제외합니다. 일반 텍스트를 쓰는 경우도 있고 정규식을 지원하거나 포함·제외 조건을 따로 제공하는 경우도 있습니다. 다른 클라이언트의 표현식을 그대로 붙여넣지 마세요. 정규식을 지원하는 필드에서는 세로 막대가 ‘또는’, 마침표가 임의의 문자 하나를 뜻할 수 있으며, 이름에 포함된 괄호도 문법으로 해석될 수 있습니다. 먼저 명확한 키워드 하나만 입력해 결과를 확인한 뒤 조건을 조금씩 추가하세요.

제외 조건은 포함 조건보다 신중하게 설정하세요. 모든 항목이 제외되면 클라이언트에 따라 이전 목록을 유지하거나 해당 그룹을 빈 목록으로 업데이트할 수 있습니다. 필터를 바꾸기 전에 현재 설정을 백업하고 사용 중인 서버의 이름과 프로토콜을 기록하세요. 필터 적용 후에는 알고 있는 항목 몇 개와 대조하세요. 목록이 짧아졌다는 이유만으로 설정이 올바르다고 판단하지 마세요. 서버 이름은 변경될 수 있으므로 출처에서 이름을 바꾸면 기존 키워드가 더 이상 일치하지 않을 수 있습니다. 필터 조건도 주기적으로 점검하세요.

업데이트는 성공했는데 연결이 안 되면 무엇을 확인해야 하나요?

업데이트 성공은 구독 내용을 가져와 해석했다는 뜻일 뿐, 모든 서버에 연결할 수 있다는 의미는 아닙니다. 먼저 현재 활성 항목이 업데이트 후에도 유효한 서버를 가리키는지 확인한 다음 프로토콜, 전송 방식, TLS, 인증 정보가 올바른지 살펴보세요. 구독 항목을 직접 수정하면 다음 업데이트에서 덮어써질 수 있습니다. 장기간 유지할 변경 사항은 별도의 설정으로 복사하고 출처를 기록하세요. 원본 항목을 수정한 뒤 구분하지 않으면 나중에 문제가 원격 변경 때문인지 로컬 수정 때문인지 파악하기 어렵습니다.

02 / 연결 경로

라우팅 규칙은 어떻게 정렬하고 검증하나요?

명확한 예외 규칙을 앞에 두고 포괄적인 기본 규칙은 뒤에 배치하세요. V2Ray 계열 코어는 일반적으로 규칙을 순서대로 확인하고 일치하는 규칙의 아웃바운드를 선택합니다. 클라이언트가 설정을 생성하며 자체 규칙을 삽입할 수도 있으므로, 화면에 표시된 순서를 최종 설정과 대조해야 합니다. 규칙이 무엇과 일치하는지는 연결에 도메인과 IP 주소 중 무엇이 포함되는지, 스니핑이 켜져 있는지, 도메인 전략이 조회를 유발하는지에 따라 달라집니다. 도메인 규칙을 추가했다고 해서 모든 연결에 사용할 수 있는 도메인 정보가 포함되는 것은 아닙니다.

도메인, 주소, 아웃바운드 태그는 각각 무엇인가요?

domain은 도메인 일치 조건을, ip는 대상 주소 일치 조건을 나타냅니다. outboundTag는 이미 정의된 아웃바운드 태그를 참조합니다. 태그는 내부 식별자이지 화면에 표시할 메모가 아닙니다. 예시의 direct, proxy, block은 모두 아웃바운드 설정에 정의되어 있어야 합니다. 한 규칙에 도메인과 주소처럼 서로 다른 유형의 조건을 함께 넣으면 일반적으로 모든 조건을 충족해야 합니다. ‘도메인 또는 주소 중 하나만 일치’시키려는 경우에는 규칙을 따로 나누세요.

아래는 일반적인 Xray/V2Ray 스타일의 라우팅 예시이며, 전체 클라이언트 설정으로 가져올 수는 없습니다. 필요한 geosite 및 geoip 데이터가 준비되어 있고 해당 아웃바운드도 정의되어 있다고 가정합니다. 광고 분류를 먼저 차단하고, 이어서 사설 주소와 중국 도메인을 처리한 뒤 나머지는 클라이언트의 기본 아웃바운드에 맡깁니다. 도메인 분류 내용은 실제 데이터 파일에 따라 달라지며 항상 동일한 목록이 아닙니다. 분류를 찾을 수 없다는 오류가 발생하면 규칙 순서를 계속 바꾸지 말고 데이터 지원 여부를 확인하세요.

{
  "routing": {
    "domainStrategy": "IPIfNonMatch",
    "rules": [
      {
        "type": "field",
        "domain": ["geosite:category-ads-all"],
        "outboundTag": "block"
      },
      {
        "type": "field",
        "ip": ["geoip:private"],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "domain": ["geosite:cn"],
        "outboundTag": "direct"
      }
    ]
  }
}

도메인 전략은 어떻게 선택해야 하나요?

AsIs는 라우팅 단계에서 주소 규칙을 위해 도메인을 능동적으로 조회하지 않는다는 뜻입니다. IPIfNonMatch는 일반적으로 도메인이 규칙과 일치하지 않을 때 조회를 시도하고, 그 결과를 사용해 계속 규칙을 검사합니다. IPOnDemand는 규칙 검사에 주소 정보가 필요할 때 조회합니다. 이 전략은 라우팅 평가에 영향을 주며 시스템 전체의 DNS 동작과는 다릅니다. 특정 도메인만 직접 연결하려는 경우에는 명확한 도메인 규칙을 사용하세요. 모든 요청이 사전에 주소 규칙 검사에 들어가도록 설정할 필요는 없습니다.

‘중국 내 웹사이트도 우회된다’면 전체 연결을 직접 연결로 바꾸기보다 먼저 규칙 일치 여부를 확인하세요. 해당 도메인이 분류에 포함되어 있는지, 앞쪽에 더 포괄적인 프록시 규칙이 있는지, 앱이 캐시된 주소에 직접 연결했는지 확인합니다. 최종 설정에서 기본 아웃바운드가 프록시라면 어떤 규칙에도 일치하지 않는 연결이 프록시를 거치는 것은 정상입니다. 문제를 좁히려면 정확한 도메인 규칙을 임시로 추가하고 같은 앱에서 새 연결을 만드세요. 기존 연결은 설정을 바꿔도 자동으로 전환되지 않을 수 있으며, 페이지를 새로고침해도 이전 연결을 재사용할 수 있습니다.

규칙이 계속 복잡해지는 것을 어떻게 막나요?

규칙을 ‘로컬 리소스, 서비스별 예외, 분류 규칙, 기본 정책’으로 나누어 기록하고 각 예외의 용도를 명확히 적으세요. 로컬 네트워크 기기에 연결할 때는 기기 도메인 분류에 의존하는 것보다 사설 주소를 직접 연결하는 편이 더 안정적입니다. 사내 도메인에는 전용 DNS가 필요할 수도 있으므로 아웃바운드만 바꿔서는 이름이 조회되지 않을 수 있습니다. 모든 포트나 모든 네트워크를 포괄하는 규칙을 앞에 두면 뒤쪽의 세부 규칙이 적용되지 않습니다. 변경 후에는 직접 연결 대상, 프록시 대상, 로컬 네트워크 대상 하나씩을 테스트하세요.

검증할 때는 대상 도메인, 앱 이름, 일치한 규칙, 아웃바운드 태그를 기록하세요. 단순히 ‘열린다’고만 적지 마세요. 웹사이트의 페이지와 이미지가 서로 다른 도메인을 사용할 수 있으므로 기본 페이지가 직접 연결된다고 해서 모든 리소스가 같은 경로를 이용하는 것은 아닙니다. 프로토콜 필드가 궁금하다면 VMess와 VLESS의 차이를 읽어보세요. 라우팅 선택과 프로토콜 선택은 별개의 단계입니다.

03 / 이름 조회

DNS 설정은 어느 단계부터 최적화해야 하나요?

먼저 조회 경로를 파악한 다음 DNS 서버를 선택하세요. 앱은 시스템 DNS, 브라우저 자체의 암호화 DNS를 사용할 수도 있고, 프록시 프로토콜을 통해 도메인을 코어에 전달할 수도 있습니다. 코어도 라우팅 판정과 직접 연결을 위해 각각 별도로 조회할 수 있습니다. 따라서 클라이언트에 DNS를 입력했다고 해서 모든 앱의 조회가 해당 DNS를 통과하는 것은 아닙니다. 최적화를 시작할 때는 여러 공개 DNS를 목록에 추가하기보다 누가 조회를 요청하는지, 요청이 어느 경로로 나가는지, 응답을 누가 사용하는지부터 확인하세요.

로컬 도메인과 외부 도메인은 왜 구분해야 하나요?

로컬 네트워크 기기 이름과 사내 도메인은 로컬이나 조직에서 제공하는 DNS만 응답할 수 있습니다. 공용 인터넷 도메인은 DNS 서버의 위치에 따라 서로 다른 CDN 주소를 반환할 수도 있습니다. 내부 도메인을 모두 공개 DNS에 맡기면 존재하지 않는다는 응답을 받을 수 있고, 공용 도메인을 모두 로컬 DNS에 고정하면 프록시 출구 위치와 맞지 않는 주소를 받을 수 있습니다. DNS 분할의 목적은 조회 결과와 이후 연결 경로를 일치시키는 것입니다. 특정 DNS가 항상 더 낫다고 정하는 것이 아닙니다.

아래 예시는 중국 도메인 분류에 한 DNS 서버를 우선 사용하고 나머지 조회에는 다른 서버를 사용하는 기본 구조입니다. dns.servers의 구성만 보여주며 조회가 프록시나 직접 연결을 통해 전송된다고 보장하지는 않습니다. 요청 경로는 코어 구현, 조회 프로토콜, 라우팅 설정에 따라 달라집니다. 이 예시로 클라이언트의 전체 DNS 설정을 덮어쓰지 마세요. 특히 TUN 환경에서는 가상 네트워크 인터페이스와 DNS 가로채기를 위해 클라이언트가 생성한 관련 설정도 보존해야 합니다.

{
  "dns": {
    "servers": [
      {
        "address": "223.5.5.5",
        "domains": ["geosite:cn"]
      },
      "1.1.1.1"
    ]
  }
}

암호화 DNS를 사용해도 연결되지 않을 수 있는 이유는 무엇인가요?

HTTPS 방식의 DNS 주소를 사용하려면 먼저 DNS 서버에 연결해야 합니다. 주소가 도메인이라면 해당 도메인부터 조회해야 하므로 부트스트랩 조회 문제가 생길 수 있습니다. 프록시 서버 주소도 도메인인데 아직 연결되지 않은 프록시를 통해서만 조회하도록 설정하면 순환 의존이 발생합니다. 먼저 프록시 서버와 DNS 서버의 도메인을 각각 독립적으로 조회할 수 있는 경로를 확보한 다음 다른 도메인의 조회 경로를 설정하세요. 임시로 서버 주소를 고정해 장기간 사용하는 것은 권장하지 않습니다. 원격 주소가 바뀔 수 있습니다.

도메인 전략과 DNS 서버 선택을 혼동하지 마세요. 라우팅의 domainStrategy는 규칙 일치를 위해 언제 조회할지를 정합니다. 직접 연결 아웃바운드에도 자체 도메인 조회 전략이 있을 수 있습니다. 라우팅에서 AsIs를 사용해도 도메인에 직접 연결하려면 마지막에 조회가 필요할 수 있습니다. 반대로 라우팅에서 이미 주소를 얻었더라도 브라우저나 다른 앱이 별도로 조회할 수 있습니다. 문제를 확인할 때는 ‘DNS 요청 경로’와 ‘서비스 연결 경로’를 나누어 살펴보고, 하나의 DNS 테스트 사이트만으로 결론 내리지 마세요.

캐시와 듀얼 스택 환경은 어떻게 점검하나요?

설정을 변경한 뒤 관련 연결을 다시 시작하고 시스템, 앱, 코어의 각 캐시를 고려하세요. 캐시가 만료되지 않았다면 테스트에 이전 결과가 사용될 수 있습니다. 듀얼 스택 네트워크에서는 주소 레코드도 구분해야 합니다. IPv4 연결만 확인해서는 IPv6 트래픽도 의도한 경로를 이용한다고 볼 수 없습니다. 특정 단계에서 IPv6 조회를 비활성화해도 앱이 캐시된 주소를 사용하는 것을 막지 못할 수 있습니다. 네트워크가 실제로 듀얼 스택을 지원한다면 조회, 라우팅, 출구 기능을 함께 점검하세요. IPv6 비활성화는 일반적인 해결책이 아닙니다.

DNS 조회는 정상인데 웹페이지가 열리지 않으면 라우팅과 전송 로그를 다시 확인하세요. 서버 거부, TLS 매개변수 불일치, 대상 연결 재설정은 DNS 서버를 바꿔도 해결되지 않습니다. 일반적인 연결 증상은 도움말 센터에서 확인할 수 있습니다.

04 / 시스템 트래픽 가로채기

TUN 모드와 시스템 프록시는 어떻게 다른가요?

TUN은 가상 네트워크 인터페이스로 시스템 트래픽을 받아들이고, 시스템 프록시는 해당 설정을 지원하는 앱에 프록시 주소를 제공합니다. 브라우저는 대개 시스템 프록시를 사용할 수 있지만 일부 터미널 도구, 백그라운드 서비스, 자체 네트워크 스택을 가진 프로그램은 이를 따르지 않을 수 있습니다. 더 넓은 범위의 트래픽을 처리해야 한다면 TUN이 적합하지만 권한, 라우팅, DNS, 가상 네트워크 인터페이스 간의 관계도 함께 고려해야 합니다. 먼저 일반 프록시 연결이 정상인지 확인한 다음 TUN을 활성화하세요. 그렇지 않으면 기본 연결과 시스템 트래픽 가로채기가 동시에 실패해 문제 범위가 넓어집니다.

활성화 전에 어떤 조건을 확인해야 하나요?

사용 가능한 설정을 저장하고 현재 시스템 프록시 상태를 기록한 다음, 클라이언트가 해당 플랫폼의 TUN 기능을 지원하는지 확인하세요. v2rayN은 데스크톱 플랫폼에 따라 보조 구성 요소나 실행 방식이 다를 수 있습니다. TUN 기능도 현재 서버에 선택된 코어가 직접 구현한다고 볼 수 없습니다. 서버 프로토콜만 보고 가상 인터페이스 지원 여부를 판단하지 마세요. 활성화할 때는 클라이언트가 요구하는 권한을 부여하세요. 인터페이스 생성이나 라우팅 변경에 실패했다는 메시지가 나오면 구독 서버를 계속 바꾸기보다 권한과 구성 요소 문제부터 해결해야 합니다.

Android의 v2rayNG와 v2flyNG는 보통 시스템 VPN 인터페이스를 통해 트래픽을 가로챕니다. 권한 요청 팝업은 시스템에서 표시하는 정상 절차입니다. 같은 시스템 인터페이스를 사용하는 다른 네트워크 도구와 동시에 사용할 수 없을 수 있으므로 충돌하는 앱을 먼저 중지하고 테스트하세요. 데스크톱에서는 기업 VPN, 가상 머신 네트워크, 보안 소프트웨어가 라우팅이나 DNS를 동시에 변경할 수 있습니다. 문제를 확인한다고 모든 네트워크 인터페이스를 삭제하지 마세요. 관련 소프트웨어를 먼저 비활성화하고 기존 설정을 보존한 뒤 클라이언트를 종료했을 때 네트워크가 자동으로 복구되는지 확인하세요.

활성화 후 로컬 네트워크 기기에 연결할 수 없는 이유는 무엇인가요?

먼저 로컬 네트워크 주소가 가로채기 대상에 포함되는지, 더 구체적인 라우팅 또는 우회 설정이 있는지 확인하세요. 프린터, 파일 공유, 관리 페이지는 사설 주소, 내부 도메인, 로컬 네트워크 검색 프로토콜을 사용할 수 있으며 이들은 서로 다른 유형의 트래픽입니다. 사설 주소를 직접 연결하도록 설정하면 코어에 들어온 일반 연결은 처리할 수 있지만 일부 브로드캐스트, 멀티캐스트, 검색 기능은 시스템 인터페이스와 가로채기 방식의 영향을 계속 받을 수 있습니다. 먼저 기기의 정확한 주소로 테스트한 다음 이름 조회와 검색을 점검하세요. 한꺼번에 도메인 예외를 많이 추가하지 마세요.

서버 연결 자체가 다시 가로채기에 들어가 순환되지 않도록 해야 합니다. 클라이언트는 보통 인터페이스 지정, 라우팅 제외 또는 다른 방식으로 이를 처리합니다. 기본 네트워크 인터페이스가 바뀌거나 다른 터널을 동시에 사용하거나 라우팅을 수동으로 수정하면 이러한 전제가 깨질 수 있습니다. 시작 후 로그에서 같은 서버 연결이 반복되거나 TUN을 끄자마자 정상화된다면 출구 인터페이스와 제외 규칙을 우선 확인하세요. 시스템 서버 주소를 일반 트래픽 프록시 규칙에 넣어 ‘가로채기를 강화’하지 마세요. 문제가 더 복잡해질 수 있습니다.

UDP, MTU, 절전 모드 복귀 문제는 어떻게 점검하나요?

웹페이지는 열리지만 음성 통화, 게임 또는 다른 UDP 앱이 작동하지 않으면 선택한 프로토콜, 서버, 전송 경로가 해당 트래픽을 전달할 수 있는지 먼저 확인하세요. TUN이 트래픽을 받아들인다고 해서 원격 서버도 반드시 전달을 지원하는 것은 아닙니다. 작은 요청은 성공하지만 큰 데이터 전송이 멈추는 경우에는 경로 MTU와 조각화 문제를 살펴보세요. 시간 초과가 발생했다고 MTU를 무작정 낮추지 마세요. 먼저 서버와 대상 서비스의 문제를 제외한 다음 클라이언트가 지원하는 범위에서 조금씩 조정하고 원래 값을 저장해 복구할 수 있도록 하세요.

기기가 절전 모드에서 깨어나거나 무선 네트워크를 바꾸면 기존 인터페이스와 기본 경로가 달라질 수 있습니다. 이때 클라이언트 연결을 다시 만들고 가상 인터페이스가 재연결됐는지 확인한 다음 시스템 DNS가 여전히 유효한 주소를 가리키는지 살펴보세요. 클라이언트를 종료한 뒤에도 인터넷이 되지 않으면 창만 닫지 말고 시스템 프록시, DNS, 라우팅을 각각 복구하세요. 브라우저와 터미널의 동작이 다른 경우 앱별 시스템 프록시 문제 해결을 참고해 앱 호환성 문제인지 시스템 가로채기 문제인지 먼저 구분하세요.

05 / 도메인 매핑

FakeDNS는 어떤 조건에서 작동하나요?

FakeDNS는 코어가 식별할 수 있도록 합성 주소를 반환합니다. 대상 웹사이트의 실제 주소를 반환하는 것은 아닙니다. 앱이 합성 주소를 받은 뒤 연결을 시작하면 코어는 이전 조회에서 저장한 도메인으로 주소를 복원한 다음 라우팅하거나 원격으로 연결합니다. 시스템 조회를 거치면서 도메인 정보가 사라지기 쉬운 가로채기 환경에서 연결이 원래 어느 도메인을 향했는지 보존할 수 있다는 장점이 있습니다. 조회와 후속 연결이 같은 연동 처리 흐름에 들어와야 합니다. 한쪽만 가로채면 연결이 실패할 수 있습니다.

조회와 연결을 모두 가로채야 하는 이유는 무엇인가요?

코어가 DNS 조회에 응답했는데 서비스 연결은 코어를 우회하면 시스템이 실제 서버가 아닌 주소로 직접 연결을 시도합니다. 반대로 앱이 자체 암호화 DNS로 실제 주소를 조회한 뒤 연결이 TUN에 들어오더라도 FakeDNS에 해당 매핑이 없을 수 있습니다. 먼저 DNS 요청이 어떤 경로로 들어오는지 확인한 다음 반환된 주소의 트래픽을 누가 받는지 확인하세요. TUN을 활성화했다는 이유만으로 매핑 경로가 완성됐다고 판단할 수는 없습니다. FakeDNS 통합 방식은 클라이언트마다 다르며 일부 가로채기 방식은 다른 설정 형식을 사용하므로 실제 구성 요소를 기준으로 확인하세요.

아래는 관련 설정 형식을 사용하는 Xray/V2Ray 코어의 예시로, 합성 주소 풀과 DNS 서버 선택만 보여줍니다. 지원되는 인바운드, 스니핑을 통한 도메인 복원, 라우팅과 함께 설정해야 하므로 이 내용만 붙여넣었다고 기능이 활성화되는 것은 아닙니다. 주소 풀이 실제 사용하는 테스트 네트워크와 겹치지 않도록 하세요. 환경에 같은 서브넷의 라우팅이 이미 있다면 먼저 충돌을 해결해야 합니다. 그래픽 클라이언트에서는 필드를 하나만 수정해 관련 설정을 빠뜨리지 않도록 클라이언트가 제공하는 전체 옵션을 우선 사용하세요.

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

FakeDNS와 스니핑은 같은 기능인가요?

아닙니다. FakeDNS는 이전 조회 기록을 이용해 도메인을 복원하고, 스니핑은 연결 초기에 전달되는 데이터에서 일부 HTTP 또는 TLS 정보 같은 애플리케이션 계층의 대상 정보를 식별합니다. 스니핑이 모든 프로토콜을 식별하는 것은 아니며, 임의의 주소를 도메인으로 자동 변환할 수도 없습니다. FakeDNS는 해당 매핑이 존재해야 작동합니다. 일부 코어는 스니핑 설정의 특정 옵션으로 FakeDNS와 연동되지만 두 기능이 사용하는 데이터의 차이는 그대로입니다. 활성화하기 전에 현재 코어가 지원하는 필드를 확인하고 서로 다른 설정 형식의 옵션 이름을 섞어 쓰지 마세요.

‘라우팅 판단에만 사용’하는 경우와 ‘실제 연결 대상을 다시 쓰는’ 경우도 구분해야 합니다. 일부 스니핑 설정은 인식한 도메인을 규칙 일치에만 사용하고 실제 연결에는 원래 주소를 유지합니다. 다른 설정은 후속 아웃바운드가 도메인을 다시 조회하게 할 수 있습니다. 두 방식 모두 CDN, 인증서 검증, 일부 앱의 호환성에 영향을 줍니다. 스니핑을 켠 뒤 특정 앱이 작동하지 않으면 대상 재작성을 끄거나 클라이언트가 지원하는 제외 규칙으로 비교 테스트하세요. 모든 도메인 규칙을 바로 삭제하지 마세요.

가로채기를 중지했는데도 앱이 연결되지 않는 이유는 무엇인가요?

앱이 합성 주소를 캐시했을 수 있습니다. FakeDNS를 비활성화해도 캐시에 남은 주소로 새 연결을 시도할 수 있지만, 이때는 코어가 주소를 복원하지 않습니다. 먼저 해당 앱의 연결을 종료하고 DNS 캐시를 지우세요. 필요한 경우 앱을 다시 시작하고 시스템 캐시와 코어의 매핑도 함께 확인해야 합니다. 시스템 캐시만 지워도 브라우저 자체에 이전 결과가 남아 있으면 문제가 계속될 수 있습니다. 설정을 전환하는 동안 앱이 새 연결을 계속 만들지 않도록 하세요. 이전 매핑과 새 조회 결과가 뒤섞일 수 있습니다.

호환성 검증에는 브라우저, 로컬 네트워크 검색이 필요한 앱, 자체 DNS를 사용하는 프로그램을 포함하세요. 일반 DNS만으로 도메인 정보를 보존하고 라우팅 요구 사항을 충족할 수 있다면 옵션이 많다는 이유만으로 FakeDNS를 켤 필요는 없습니다. 사용해야 한다면 앱 하나로 조회, 매핑 복원, 아웃바운드가 예상대로 동작하는지 먼저 검증한 뒤 가로채기 범위를 넓히세요. 문제가 생기면 스니핑과 재작성 설정을 더 추가하지 말고 일반 DNS 설정으로 되돌리세요.

06 / 업데이트 및 관리

여러 구독이 서로 덮어쓰지 않도록 관리하려면 어떻게 해야 하나요?

원격에서 관리되는 구독과 로컬에서 관리하는 설정을 분리하세요. 여러 구독은 서로 다른 출처나 용도의 서버를 제공하지만 자동으로 장애 조치가 되지는 않으며, 이름이 비슷하다고 매개변수를 공유하지도 않습니다. 출처마다 별도 그룹을 만들고 로컬 수정 사항은 따로 저장한 뒤 메모에 용도를 적어두세요. 이렇게 하면 업데이트가 실패했을 때 해당 출처만 처리할 수 있고 오래된 구독을 삭제할 때 영향 범위도 쉽게 파악할 수 있습니다. 모든 주소와 수동으로 추가한 서버를 한 그룹에 섞어두지 마세요. 목록 순서만으로 현재 사용 중인 항목을 기억하는 것도 위험합니다.

이름이 같은 서버와 중복 가져오기는 어떻게 처리하나요?

먼저 출처와 주요 연결 매개변수를 비교한 뒤 실제로 중복인지 판단하세요. 서버 이름이 같아도 포트, 프로토콜, 전송 방식이 다를 수 있습니다. 설정 이름을 바꿨다고 새로운 서버가 된다는 보장도 없습니다. 클라이언트는 주소, 프로토콜 필드, 내부 식별자를 기준으로 중복을 처리할 수 있으므로 ‘중복 제거’를 실행하면 수동 수정 항목이 반드시 남는다고 가정하지 마세요. 일괄 정리 전에는 백업을 내보내고 알고 있는 항목 몇 개로 확인한 뒤 전체 정리를 진행하세요. 목록에서 찾기 어려운 것뿐이라면 삭제하기보다 그룹과 필터를 개선하세요.

기기 간 이동 시 관리 설정도 보존해야 합니다. 단일 공유 링크를 내보내도 구독 업데이트 설정, 라우팅, DNS, 클라이언트 기본 설정은 보통 포함되지 않습니다. 전체 설정을 내보내면 더 많은 민감 정보가 들어갈 수 있습니다. 이전하려는 대상이 서버 매개변수인지 전체 클라이언트 환경인지 먼저 정하세요. 데스크톱과 Android 클라이언트는 전체 설정 형식이 동일하다고 보장하지 않습니다. 데스크톱 내부 설정을 모바일 설정으로 직접 가져오기보다 구독을 다시 설정하고 목차에 따라 규칙을 옮기는 편이 안전합니다.

자동 업데이트는 언제 활성화해야 하나요?

먼저 수동으로 업데이트하고 결과를 확인한 다음 주기를 설정하세요. 업데이트 빈도는 출처의 실제 변경 주기에 맞추면 됩니다. ‘최신 상태’를 유지하려고 지나치게 자주 요청할 필요는 없습니다. 기기 절전, 네트워크 전환, 일시적인 출처 연결 불가로 예약 업데이트가 실패할 수 있습니다. 일부 클라이언트는 실행 중에만 작업하므로 주기를 설정해도 기기가 꺼져 있을 때 업데이트되는 것은 아닙니다. 직접 연결로 가져오는 일반 업데이트와 프록시를 통한 업데이트도 구분해야 합니다. 후자는 현재 연결이 정상이어야 합니다. 구독을 프록시를 통해서만 가져올 수 있다면 검증된 연결 설정을 하나 보존하세요.

업데이트와 현재 서버 전환은 서로 다른 작업입니다. 출처에서 현재 항목을 제거해도 클라이언트가 재시작 전까지 이미 불러온 설정을 계속 사용하거나, 다시 불러올 때 유효하지 않다는 메시지를 표시할 수 있습니다. 업데이트가 끝나면 현재 활성 항목이 남아 있는지 확인한 다음 연결을 새로 만들고 검증하세요. 클라이언트가 지원하는 선택 기능을 실제로 설정하지 않았다면 특정 서버가 자동 선택된다고 가정하지 마세요. 화면 정렬, 테스트 결과 정렬, 현재 활성 상태는 각각 별개입니다. 첫 번째 줄에 있다고 사용 중인 것은 아닙니다.

구독 가져오기에 실패하면 어떤 순서로 확인해야 하나요?

먼저 주소가 완전한지 확인하고, 다음으로 가져오는 경로를 점검한 뒤 형식을 확인하세요. 복사 과정에서 쿼리 매개변수가 빠지거나 끝에 공백이 붙거나 출처가 로그인 페이지를 반환하면 파싱 오류로 표시될 수 있습니다. 오류가 연결 시간 초과인지, 인증 거부인지, 콘텐츠 파싱 실패인지 먼저 확인한 다음 다음 단계를 결정하세요. 연결 실패라면 네트워크와 프록시를 통한 업데이트 경로를 점검하고, 인증 거부라면 출처의 권한을 확인하세요. 콘텐츠 파싱 실패라면 형식 호환성을 확인합니다. 전체 구독 주소를 공개 게시물에 붙여넣지 마세요. 오류 메시지에 인증 정보가 표시될 수도 있습니다.

백업 파일도 민감 정보로 취급해 안전하게 보관하세요. 스크린샷을 공유하기 전 주소, 인증 필드, 개인 메모를 가리세요. 이전이 끝나면 임시 내보내기 파일을 정리합니다. 클라이언트를 새로 설치하려면 클라이언트 다운로드 페이지에서 플랫폼에 맞는 파일을 선택하고, 새 환경이 정상인지 확인한 뒤 기존 환경을 제거하세요. 다중 구독 관리의 목적은 출처, 업데이트, 로컬 변경 사항을 추적할 수 있게 하는 것입니다. 목록을 길게 만드는 것이 아닙니다. 각 그룹의 용도를 명확히 설명할 수 있는 편이 중복 설정을 많이 보유하는 것보다 중요합니다.

07 / 설정 조합

사용자 지정 아웃바운드는 라우팅과 어떻게 연결하나요?

먼저 아웃바운드를 정의하고 라우팅에서 해당 태그를 참조하세요. 아웃바운드는 코어가 연결을 내보내는 방식을, 라우팅은 어떤 연결을 어느 아웃바운드에 전달할지를 정합니다. 클라이언트의 ‘사용자 지정 설정’은 기존 설정에 일부 내용을 추가하는 것이 아니라 전체 설정을 대체한다는 뜻일 수 있습니다. ‘사용자 지정 아웃바운드’도 특정 필드만 편집할 수 있다는 의미일 수 있습니다. 편집 범위를 먼저 확인하세요. 그렇지 않으면 아웃바운드 객체를 붙여넣었을 때 전체 설정으로 해석되거나 클라이언트가 자동 생성한 로컬 리스너와 DNS 설정이 덮어써질 수 있습니다.

태그와 기본 아웃바운드에는 어떤 제약이 있나요?

아웃바운드 태그는 고유하고 안정적이며 알아보기 쉬워야 합니다. 라우팅에서 태그를 참조할 때 대소문자와 철자를 일치시키고 서버 메모를 태그로 착각하지 마세요. 일반적인 V2Ray/Xray 설정은 규칙에 일치하는 항목이 없을 때 첫 번째 아웃바운드를 사용하지만 그래픽 클라이언트가 순서를 바꾸거나 기본 항목을 생성할 수 있으므로 최종 실행 설정을 기준으로 확인해야 합니다. 특정 트래픽을 직접 연결하려고 전체 아웃바운드 순서를 바꾸지 마세요. 해당 라우팅 규칙을 추가하면 변경 범위를 명확히 하고 쉽게 복구할 수 있습니다.

아래는 직접 연결, 차단, 로컬 SOCKS 서비스 연결의 세 가지 구조를 보여주는 기본 아웃바운드 예시입니다. 전체 설정이 아니며, 지정한 포트에서 실제로 사용할 수 있는 SOCKS 서비스가 실행 중일 때만 세 번째 항목이 유효합니다. 해당 서비스가 현재 코어의 인바운드 포트를 가리키면 순환이 발생합니다. 예시는 루프백 주소를 사용해 로컬 보조 서비스가 로컬 네트워크에 노출되지 않도록 합니다. 다른 기기에서 접근해야 한다면 수신 범위, 인증, 접근 제어를 별도로 설정하세요.

{
  "outbounds": [
    {
      "tag": "direct",
      "protocol": "freedom",
      "settings": {}
    },
    {
      "tag": "block",
      "protocol": "blackhole",
      "settings": {}
    },
    {
      "tag": "local-socks",
      "protocol": "socks",
      "settings": {
        "servers": [
          {
            "address": "127.0.0.1",
            "port": 1081
          }
        ]
      }
    }
  ]
}

체인 연결이 구독 여러 개와 다른 이유는 무엇인가요?

여러 구독은 설정 출처가 여러 개라는 뜻입니다. 체인 연결은 한 아웃바운드의 하위 연결이 다른 아웃바운드나 보조 서비스를 거치도록 구성해야 합니다. 필드는 실행 중인 코어와 프로토콜 구현에 따라 다르므로 서로 다른 코어의 조합 방식을 바꿔 쓸 수는 없습니다. 화면에서 앞단 프록시를 선택할 수 있더라도 그것이 구독 가져오기, 서버 연결, 서비스 트래픽 중 어디에 적용되는지 확인하세요. 세 경로의 범위는 서로 다릅니다. ‘앞단’이라는 이름만 보기보다 각 홉의 대상 주소와 연결 책임을 먼저 그려보는 편이 확실합니다.

홉을 하나 추가할 때마다 의존성이 늘어나므로 장애가 발생하면 가장 바깥쪽 연결부터 확인하세요. 먼저 로컬 보조 서비스가 동작하는지, 다음으로 해당 서비스가 대상 서버에 연결되는지, 마지막으로 서비스 규칙이 실제로 그 아웃바운드를 선택하는지 검증합니다. 서로를 가리키는 프록시를 여러 개 동시에 켜지 마세요. 특히 시스템 프록시, TUN, 로컬 SOCKS 서비스가 서로의 트래픽을 전달하도록 구성하지 마세요. 로그가 빠르게 반복되거나 연결이 계속 끊겼다 다시 맺어진다면 먼저 순환을 제외하고 인증과 전송 매개변수를 확인하세요.

프로토콜 매개변수와 전송 매개변수는 따로 복사해도 되나요?

하나의 세트로 확인해야 합니다. 주소, 포트, 인증, 전송 유형, TLS 이름, 추가 보안 매개변수가 함께 연결 성립 여부를 결정합니다. 아웃바운드 프로토콜만 바꾸고 기존 전송 매개변수를 유지하면 형식은 맞지만 작동하지 않는 설정이 될 수 있습니다. REALITY와 관련 흐름 제어 필드도 서버 설정과 일치해야 합니다. 최신 기능처럼 보인다는 이유만으로 임의로 켜지 마세요. 필드 간 관계는 REALITY와 XTLS Vision 원리 설명에서 확인한 다음 현재 코어가 지원하는 범위를 살펴보세요.

저장 후 설정이 자동으로 원래 값으로 돌아간다면 구독 업데이트, 템플릿 생성, 화면에서 설정을 다시 기록하는 동작 때문일 수 있습니다. 실행 중인 임시 파일을 반복해서 수정하지 말고 실제 설정 출처를 찾거나 클라이언트가 지원하는 영구 사용자 지정 메뉴를 사용하세요. 전체 사용자 지정 설정은 그래픽 인터페이스의 일부 옵션을 우회할 수도 있습니다. 화면에 활성화된 것으로 보여도 해당 필드가 실제 설정에 기록되지 않았을 수 있습니다. 실행 로그, 생성된 설정, 실제 연결 결과를 함께 확인해 판단하세요.

08 / 검증 및 복구

설정 변경 후 어떻게 검증하고 복구하나요?

‘연결된다’는 말을 관찰 가능한 여러 단계로 나누어야 변경이 올바른지 판단할 수 있습니다. 구독 업데이트, 코어 시작, 서버 연결, DNS 응답, 라우팅 아웃바운드 선택, 앱 접속은 각각 다른 점검 단계입니다. 고급 설정을 바꾸기 전에 정상 동작이 확인된 기준 설정을 보존하고, 한 번에 한 종류만 변경하세요. 프로토콜, DNS, TUN, 규칙을 동시에 바꾸면 연결이 복구되더라도 어떤 변수가 영향을 미쳤는지 알기 어렵습니다.

먼저 고정된 테스트 대상을 정하세요

접근 권한이 있고 동작이 명확한 대상을 선택해 직접 연결, 프록시, 로컬 네트워크 상황을 각각 확인하고 같은 앱에서 반복 테스트하세요. 여러 도메인, 캐시 콘텐츠, 외부 리소스를 포함할 수 있는 종합 테스트 웹페이지 하나만 사용하지 마세요. 대상, 시간, 현재 서버, 모드, 증상만 기록하면 됩니다. 인증 정보를 공개할 필요는 없습니다. 테스트 도메인의 CDN 주소가 바뀌면 한 번의 결과로 규칙이 계속 유효하다고 판단할 수 없습니다. 로그를 함께 확인해 실제로 일치한 규칙을 살펴보세요.

테스트 전에 기존 연결을 종료하세요. 브라우저는 연결을 재사용할 수 있고 백그라운드 앱은 긴 세션을 유지할 수 있습니다. 라우팅을 저장해도 이러한 세션이 반드시 새로 연결되는 것은 아닙니다. 필요하면 새로고침만 하지 말고 해당 앱을 종료한 뒤 다시 실행하세요. 비교 테스트에서는 같은 네트워크, 같은 조회 방식, 같은 대상을 사용하는 등 나머지 조건을 일치시켜야 합니다. 네트워크를 전환하면 기본 경로와 DNS가 달라지므로 전환 후의 모든 변화를 방금 바꾼 클라이언트 설정 탓으로 돌릴 수는 없습니다.

로그는 어느 부분부터 확인해야 하나요?

먼저 시작 단계에서 설정이 정상적으로 로드됐는지 확인한 다음 대상 연결 전후의 오류를 살펴보세요. 지원되지 않는 필드, 존재하지 않는 태그, 누락된 데이터 파일, 포트 충돌은 시작 또는 로드 단계의 문제입니다. 연결 거부, 인증 실패, DNS 시간 초과는 그 이후에 발생합니다. 대상 관련 로그가 전혀 없다면 먼저 앱 트래픽이 클라이언트에 들어오지 않았을 가능성을 확인하세요. 서버부터 바꾸지 마세요. 로그 수준을 높이는 것은 짧은 문제 분석에만 사용하고, 완료 후 적절한 수준으로 복구하세요. 장기간 기록하면 접속 대상이 로그에 쌓일 수 있습니다.

서버 시간 초과는 로컬 조건부터 원격 환경까지 순서대로 점검하세요. 시스템 시간, 네트워크 연결, 구독 매개변수를 확인한 다음 코어 로그에서 전송 및 보안 설정을 살펴봅니다. 목록에 표시된 한 번의 테스트 결과만으로 앱에서 연결할 수 있다고 단정할 수 없습니다. 일부 테스트는 서버 연결만 확인하고 실제 서비스 대상까지 접속하지 않습니다. 서버 시간 초과 문제 해결 순서를 참고해 로컬, 연결 경로, 서버 측 문제를 나누어 기록하세요. 이미 올바른 규칙을 반복해서 바꾸지 않도록 주의하세요.

실행 가능한 복구 순서는 어떻게 정하나요?

먼저 가장 최근의 설정 변경을 취소하고 클라이언트를 다시 불러온 뒤 연결을 새로 만드세요. 그래도 실패하면 TUN이나 다른 가로채기 기능을 끄고 이전 시스템 프록시와 DNS 상태를 복원합니다. FakeDNS를 사용했다면 앱과 시스템 캐시도 정리해 합성 주소가 남지 않도록 해야 합니다. 복구란 모든 옵션을 끄는 것이 아니라 검증된 상태로 돌아가는 것입니다. 기준 상태를 기록할 때는 현재 모드와 기본 아웃바운드도 포함하세요. 규칙 파일만 복원해도 모드가 다르면 결과가 달라질 수 있습니다.

백업은 클라이언트 데이터와 다른 환경에서도 사용할 수 있는 설정 조각을 구분하세요. 전체 데이터는 같은 환경을 복원하기 쉽고, 라우팅 및 DNS 조각은 변경 내용을 이해하는 데 유용하지만 둘 다 민감한 정보를 포함할 수 있습니다. 클라이언트를 업그레이드하거나 다른 플랫폼으로 옮기기 전에는 기존 설정을 보존하고 새 환경이 필드와 데이터 분류를 지원하는지 확인하세요. 다른 코어에서 불러올 수 있는 설정 조각을 범용 표준으로 간주하지 마세요. 지원되지 않는 필드가 있다면 오류가 난 필드를 무작정 삭제해 코어만 실행시키지 말고 해당 기능을 대신할 설정이 있는지 확인하세요.

마지막으로 세 가지 질문에 답할 수 있어야 합니다. 이번에 어떤 설정 단계를 바꿨는가, 어떤 증거로 변경이 적용됐다고 판단하는가, 실패하면 어떻게 복구하는가. 이 세 가지를 설명할 수 있어야 설정을 꾸준히 관리할 수 있습니다. 다음에 비슷한 문제가 생기면 임시 규칙을 계속 추가하기보다 같은 테스트와 기록 방식을 활용하세요.