설정 가이드

V2Ray 고급 설정: 구독, 라우팅, DNS 및 아웃바운드

설정 흐름에 따라 구독 그룹, 라우팅 판정, DNS 해석, TUN 연결 및 사용자 지정 아웃바운드를 설명하며, v2rayN, v2rayNG, v2flyNG에 적용할 수 있습니다.

설정 기준선부터 시작 빠른 시작 보기
구독 그룹 다중 구독 관리 라우팅 규칙 DNS TUN FakeDNS 사용자 지정 아웃바운드

사용 가이드에서는 “클라이언트 설치, 구독 가져오기, 서버 선택, 시스템 프록시 켜기”라는 빠른 시작 흐름을 다룹니다. 이 페이지에서는 설정이 어떻게 연동되는지와 변경 후 검증 방법을 설명합니다. 처음 사용하는 경우 먼저 빠른 시작을 완료한 다음 이 가이드로 돌아와 그룹, 분할 라우팅, DNS 및 복잡한 네트워크 연결을 설정하세요. 아직 클라이언트를 설치하지 않았다면 다운로드 페이지에서 플랫폼에 맞는 설치 패키지를 선택하세요. 데스크톱에서는 v2rayN을 우선 권장하며, Android에서는 커널 요구 사항에 따라 v2rayNG 또는 v2flyNG를 선택할 수 있습니다.

설정 기준선: 재현 가능한 작동 상태부터 고정하기

최소 작동 경로 만들기

고급 설정은 모든 옵션을 켜는 데서 시작하지 않고, 반복해서 검증할 수 있는 최소 경로를 만드는 데서 시작합니다. 정상 작동이 확인된 구독 하나, 서버 하나, 기본 라우팅과 클라이언트 기본 DNS만 남기고 LAN 공유, TUN, FakeDNS 및 추가 아웃바운드는 끄세요. 데스크톱에서는 v2rayN에서 서버를 선택한 뒤 시스템 프록시를 활성화합니다. Android에서는 v2rayNG 또는 v2flyNG에서 같은 유형의 서버를 선택하고 연결을 설정합니다. 이때는 세 가지만 확인하세요. 클라이언트 코어가 시작되는지, 브라우저 요청이 예상한 출구를 통과하는지, 로컬 네트워크 리소스에 계속 접근할 수 있는지입니다. 하나라도 충족되지 않으면 라우팅 규칙을 계속 추가하지 말고 구독 매개변수나 서버 상태로 먼저 돌아가야 합니다.

기준선에는 명확한 기록이 포함되어야 합니다. 현재 클라이언트, 사용 중인 코어 계열, 구독 그룹 이름, 활성 서버 이름, 시스템 프록시 모드, 원격 DNS 사용 여부를 적어 두세요. 목적은 복잡한 장부를 장기간 관리하는 것이 아니라, 변경 후 “어떤 설정이 달라졌는가”에 정확히 답하는 것입니다. 클라이언트가 구독을 업데이트하면 서버 객체가 덮어써질 수 있지만, 수동으로 변경한 전역 라우팅이 자동으로 복원되는 경우는 드뭅니다. 따라서 구독 상태와 전역 설정을 분리해 확인해야 합니다.

네 가지 설정 계층 구분하기

정상 작동하는 V2Ray 그래픽 클라이언트 설정은 보통 네 계층으로 구성됩니다. 첫 번째는 주소, 포트, 사용자 식별자, 전송 방식과 보안 매개변수를 저장하는 서버 객체입니다. 두 번째는 구독과 그룹으로, 서버가 어떻게 업데이트되고 표시되며 필터링되는지를 결정합니다. 세 번째는 시스템 프록시와 TUN을 포함한 로컬 연결 방식입니다. 네 번째는 DNS, 라우팅, 인바운드와 아웃바운드를 포함하는 코어 설정입니다. 서버에 연결된다는 사실은 첫 번째 계층이 기본적으로 올바르다는 뜻일 뿐, DNS나 분할 라우팅이 예상대로 작동한다는 의미는 아닙니다. 반대로 브라우저에서 페이지가 열리지 않는다고 해서 반드시 서버 장애인 것도 아닙니다. 시스템 프록시가 해당 앱을 연결하지 못했거나, DNS가 적절하지 않은 결과를 반환했거나, 규칙이 트래픽을 잘못된 출구로 보냈을 때도 비슷한 현상이 나타납니다.

설정 계층 주요 객체 우선 확인할 항목 일반적인 영향 범위
서버 주소, 포트, 프로토콜, 전송 코어가 연결을 수립하는지 개별 서버
구독 업데이트, 그룹, 필터링 서버가 올바르게 분류되었는지 서버 그룹
연결 방식 시스템 프록시, TUN 대상 앱이 클라이언트로 들어오는지 개별 앱 또는 전체 시스템
코어 DNS, 라우팅, 인바운드, 아웃바운드 요청의 최종 경로 모든 매칭 트래픽

백업, 이름 지정 및 롤백

변경하기 전에 클라이언트가 제공하는 설정 내보내기 또는 백업 기능으로 현재 상태를 저장하세요. 파일 이름에는 용도만 명확히 적으면 됩니다. 예를 들어 “기본 라우팅”, “TUN 테스트 전”, “이중 구독 병합 전”처럼 지정할 수 있습니다. 여러 실험 목표를 하나의 백업 이름에 넣지 마세요. 클라이언트가 라우팅 설정 프로필을 지원하면 기존 프로필을 복사한 뒤 편집하세요. 전역 설정 하나만 지원한다면 먼저 코어 설정 텍스트를 복사해 두세요. 롤백할 때는 시스템 프록시 상태도 함께 확인해야 합니다. 설정 파일을 복원해도 운영체제의 프록시 스위치까지 복원되지 않는 경우가 있기 때문입니다.

이름은 감정적인 판단이 아니라 용도를 설명해야 합니다. “업무 직결 우선”, “전체 프록시 테스트”, “로컬 도메인 유지”가 “설정 1”, “최고 속도 설정”보다 관리하기 쉽습니다. 서버 이름에는 구독 제공자가 표시한 지역, 프로토콜 및 배율 정보를 유지하고, 필터 규칙은 안정적인 필드를 기준으로 작성하세요. 구독을 업데이트하면 정렬 순서가 바뀔 수 있으므로 목록 번호에 의존하지 마세요. 라우팅과 아웃바운드에는 direct, proxy, block, dns-out처럼 고정된 태그를 사용하면 규칙 참조 오류를 줄일 수 있습니다.

로그로 설정 적용 확인하기

변경할 때마다 코어를 다시 불러오고 설정 구문 오류, 포트 사용 중, 권한 부족 또는 DNS 요청 실패가 로그에 나타나는지 확인하세요. 로그 수준은 먼저 정보 수준으로 사용하고, 특정 문제를 찾을 때만 잠시 디버그 수준으로 전환한 뒤 완료되면 되돌리세요. 연결 세부 정보가 많아져 중요한 이벤트가 묻히는 것을 막을 수 있습니다. 로그는 마지막 줄부터 거꾸로 추측하지 말고 첫 번째 오류부터 읽으세요. failed to parse config가 나타나면 JSON 쉼표, 필드 계층 및 태그 참조를 먼저 점검하세요. 코어가 정상적으로 시작되었지만 요청이 시간 초과되면 서버, DNS 및 라우팅으로 범위를 넓힙니다.

기준선 검증이 끝나면 설정을 복사한 뒤 다음 장으로 넘어가세요. 이후 모든 장에서도 같은 원칙을 따릅니다. 목표를 정하고, 하나의 계층만 변경하고, 다시 불러온 다음 로그와 실제 접속 결과로 검증하고, 실패하면 롤백합니다. 구체적인 오류 문구가 관련된 경우 V2Ray 런타임 로그 읽는 방법을 참고해 단계별로 원인을 찾으세요. 클라이언트를 반복해서 재설치할 필요는 없습니다.

구독 그룹과 서버 필터링: 서버를 수동으로 삭제하지 말고 목록 제어하기

구독 소스와 사용 화면 분리하기

구독 소스는 서버 객체를 제공하고, 그룹은 객체를 선택하기 좋은 화면으로 정리합니다. 두 계층을 섞어서는 안 됩니다. 당장 사용하지 않는 서버를 직접 삭제하면 간단해 보이지만, 다음 구독 업데이트 때 다시 나타나는 경우가 많습니다. 더 안정적인 방법은 전체 구독 소스를 유지하면서 그룹, 메모 및 필터 조건으로 표시 범위를 제어하는 것입니다. v2rayN은 데스크톱에서 많은 서버를 구독 그룹별로 관리하기에 적합하고, v2rayNG와 v2flyNG는 모바일에서 후보를 적게 유지해 목록 스크롤과 오선택을 줄이는 데 적합합니다.

그룹을 만들 때는 먼저 출처별로 나눈 다음 용도별 필터 화면을 만드세요. 예를 들어 “주 구독”, “보조 구독”은 출처를 설명하고, “일상 사용”, “저배율”, “특정 프로토콜”은 용도를 설명합니다. 출처 그룹은 업데이트와 장애 격리에 사용하고, 용도 필터는 실제 선택에 사용합니다. 서로 다른 출처에 완전히 같은 이름을 붙이지 마세요. 구독 업데이트가 실패했을 때 영향을 받은 범위를 파악하기 어려워집니다. 수동으로 추가한 서버는 별도 그룹에 넣어 구독 업데이트 시 수동 객체까지 소스와 동기화된다고 착각하지 않도록 하세요.

관리하기 쉬운 필터식 설계하기

서버 필터링은 보통 이름에 포함된 지역, 프로토콜, 배율 또는 용도 태그를 기준으로 합니다. 먼저 구독 이름의 안정적인 구조를 확인한 뒤 포함 또는 제외 규칙을 작성하세요. 이름이 오랫동안 “지역｜프로토콜｜배율” 형식을 유지한다면 키워드 조합을 사용할 수 있습니다. 구분자가 자주 바뀐다면 안정적인 단어 구간만 사용하세요. 정규식은 같은 의미의 이름을 묶을 때 적합하지만 짧게 유지해야 합니다. “홍콩 또는 싱가포르”를 필터링하려면 香港|HK|新加坡|SG를 사용할 수 있고, 테스트 또는 만료된 객체를 제외하려면 测试|到期|剩余流量을 사용할 수 있습니다. 포함 규칙과 제외 규칙이 함께 있을 때는 클라이언트의 실행 순서를 먼저 확인하세요. 일반적으로 포함 항목을 남긴 뒤 그 결과에서 제외 항목을 제거합니다.

포함:
香港|HK|新加坡|SG

제외:
测试|到期|剩余流量|官网

프로토콜 선호:
VLESS|VMess|Trojan

배율 필터:
(^|[^0-9])1(\.0)?x([^0-9]|$)

배율 필터는 특히 잘못 매칭되기 쉽습니다. 문자 1만 검색하면 포트, 번호 또는 “1.5x”까지 함께 매칭될 수 있으므로 가능한 한 경계를 제한하세요. 구독 이름이 통일되어 있지 않다면 배율 필터를 요금 산정 기준으로 사용하지 마세요. 먼저 구독 제공 정보와 대조한 뒤 이름 필터는 목록 정리 용도로만 사용합니다. 지역 필터 역시 이름에 붙은 태그일 뿐 실제 네트워크 경로와 같지는 않습니다. 서버를 선택할 때는 실제 연결 테스트, 프로토콜 호환성 및 접속 결과를 함께 고려하세요. 자세한 방법은 지연 시간, 배율 및 지역으로 서버 필터링하기를 참고할 수 있습니다.

정렬, 테스트 및 선택의 역할

목록 정렬은 후보 범위를 줄이고, 지연 시간 테스트는 연결할 수 없는 객체를 제외하는 데 사용합니다. 최종 선택은 실제 업무 연결 결과를 기준으로 해야 합니다. 기본 지연 시간은 탐색 대상의 응답만 보여 주며 웹 페이지 로딩, 장시간 연결 또는 대용량 파일 전송을 완전히 대표하지 않습니다. 실제 연결 지연 시간은 코어가 프록시 연결을 수립하는 데 걸리는 시간에 더 가깝지만 테스트 대상과 당시 네트워크 상태의 영향도 받습니다. 올바른 순서는 필터로 후보를 소수로 줄이고, 실제 연결 테스트를 수행한 뒤, 실제 앱에서 검증하는 것입니다. 한 번의 테스트 결과를 그룹 이름에 영구적으로 기록하지 마세요.

자동 정렬 후 검증된 안정 서버 하나를 롤백용으로 남겨 두세요. 항상 첫 번째에 있을 필요는 없지만 알아보기 쉬운 메모가 있어야 합니다. 구독을 자주 업데이트한다면 현재 그룹 안에서만 정렬하도록 범위를 제한해 서로 다른 출처와 용도의 서버가 섞이지 않게 하세요. 그룹이 갑자기 비어 있으면 먼저 필터를 끄고 원본 목록을 확인하세요. 원본 목록이 있으면 필터 조건이 더 이상 일치하지 않는다는 뜻이고, 원본 목록도 비어 있을 때만 구독 업데이트를 점검하면 됩니다.

이름 중복과 중복 객체 처리하기

여러 구독에서 같은 이름의 서버를 제공할 수 있습니다. 표시 이름만으로 동일한 객체라고 판단하지 마세요. 주소, 포트, 사용자 식별자, 전송 매개변수 또는 출처 중 하나라도 다르면 서로 다른 객체로 취급해야 합니다. 클라이언트의 중복 제거 기능이 전체 설정을 기준으로 판단한다면 일반적으로 안전하게 사용할 수 있지만, 메모 이름만 기준으로 한다면 유효한 후보를 잘못 삭제할 수 있습니다. 더 안전한 방법은 그룹 계층에서 출처 정보를 유지하고 표시 이름의 접두사로 구분하는 것입니다. 구독 내부의 핵심 매개변수를 직접 수정하지 마세요.

필터 규칙은 정기적으로 역검사를 해야 합니다. 제외 항목에 정상 서버가 섞이지 않았는지, 미분류 항목에 새로운 이름 형식이 나타나지 않았는지 확인하세요. 구독을 업데이트할 때마다 전체를 다시 만들 필요는 없으며 포함, 제외, 미매칭 세 집합만 표본 검사하면 됩니다. 이렇게 하면 목록을 깔끔하게 유지하면서도 지나치게 엄격한 표현식 때문에 사용 가능한 서버를 잃지 않을 수 있습니다.

다중 구독 관리: 업데이트 격리, 우선순위 및 장애 전환

주 구독과 보조 구독의 역할 정하기

다중 구독은 모든 서버를 하나의 목록에 쌓는 것이 아니라 출처마다 명확한 역할을 부여하는 방식입니다. 주 구독은 일상적인 선택을 담당하고, 보조 구독은 주 소스의 업데이트 실패, 프로토콜 비호환 또는 특정 지역을 사용할 수 없을 때만 활성화합니다. 수동 그룹에는 장기간 고정해 둘 객체나 임시 테스트 객체를 보관합니다. 역할이 명확하면 업데이트 문제가 전체 목록으로 확산되지 않습니다. v2rayN에서는 구독 그룹을 각각 업데이트하고 결과를 확인할 수 있으며, 모바일에서는 새로 고칠 때마다 너무 큰 서버 목록이 재생성되지 않도록 활성화 수를 제한해야 합니다.

각 구독에 별도의 메모를 남기고 사용 중인 필터 조건도 기록하세요. 같은 그룹에서 “출처”와 “용도”라는 두 가지 이름 규칙을 섞지 마세요. 예를 들어 “주 구독”과 “보조 구독”은 출처이고, “업무”와 “스트리밍 테스트”는 용도입니다. 교차 관리가 필요하다면 원본 객체를 옮기지 말고 출처 그룹에서 필터 화면을 만들어 후보를 생성하세요. 그러면 구독 업데이트 후 화면을 다시 계산할 수 있고 출처 경계도 그대로 유지됩니다.

업데이트 순서와 실패 처리 정하기

구독은 출처별로 순서대로 업데이트해야 합니다. 먼저 주 구독을 업데이트하고 반환된 내용을 해석할 수 있는지, 서버 수에 이상이 없는지, 기존의 안정적인 객체가 남아 있는지 확인한 다음 보조 소스를 업데이트하세요. 모든 출처를 한 번에 업데이트하면 작업은 줄지만 어느 주소, 콘텐츠 형식 또는 네트워크 경로에서 문제가 발생했는지 알기 어려워집니다. 클라이언트에는 업데이트 성공으로 표시되지만 목록이 비어 있다면 필터 규칙이 구독 내용을 모두 제외했는지 확인하세요. 해석 실패로 표시되면 기존 목록을 유지한 채 구독 주소와 반환 형식을 점검하고 로컬 데이터를 먼저 비우지 마세요.

업데이트 실패는 세 가지 상황으로 나누어야 합니다. 요청이 완료되지 않은 경우, 내용은 반환되었지만 해석할 수 없는 경우, 해석은 성공했지만 결과가 예상과 다른 경우입니다. 요청 미완료는 네트워크, 시스템 프록시 또는 구독 주소부터 확인하고, 해석 실패는 콘텐츠 형식과 클라이언트 호환성을 중점적으로 점검합니다. 결과 이상은 업데이트 전후의 이름과 그룹을 비교하세요. 보조 구독은 연결 능력을 유지하기 위한 것이며 주 구독을 자동으로 덮어써서는 안 됩니다. 주 소스가 복구된 뒤 정상 순서로 전환해 두 출처가 동시에 자주 변하지 않도록 하세요.

자동 업데이트의 범위 제어하기

자동 업데이트는 안정적인 소스에 적합하지만, 서버 자동 선택과 결합해 관찰할 수 없는 블랙박스로 만들면 안 됩니다. 구독 내용이 바뀌면 새 객체가 정렬 규칙에 따라 목록 앞쪽에 나타날 수 있습니다. 여기에 클라이언트가 첫 번째 항목을 자동으로 선택하면 명확한 조작 없이 실제 출구가 바뀝니다. 더 안전한 설정은 구독을 정기적으로 새로 고치되 현재 활성 서버는 유지하고, 현재 객체가 무효가 되었을 때만 수동으로 전환하는 것입니다. 높은 안정성이 필요한 환경에서는 업데이트 빈도를 낮추고 업데이트 전에 설정을 내보내세요.

여러 기기에서 같은 구독을 사용하더라도 목록을 완전히 같게 만들 필요는 없습니다. 데스크톱에는 테스트용 지역과 프로토콜을 더 많이 남겨 두고, Android에는 자주 사용하는 후보만 남길 수 있습니다. 설정 동기화의 핵심은 목록 순서가 아니라 그룹 로직, 라우팅 대상 및 DNS 정책이어야 합니다. 클라이언트마다 구독 필드, 라우팅 화면 및 코어 옵션을 표시하는 방식이 다르므로 전체 데이터 디렉터리를 강제로 복사하면 플랫폼별 설정이 섞일 수 있습니다.

구독 내용이 전역 설정을 오염시키지 않도록 하기

구독 업데이트의 이상적인 범위는 서버 객체를 갱신하는 것이며 전역 DNS, 라우팅 및 로컬 인바운드를 덮어쓰는 것이 아닙니다. 클라이언트가 “구독 업데이트 시 추가 설정 가져오기”를 지원한다면 활성화하기 전에 어떤 계층을 변경하는지 이해해야 합니다. 출처가 불명확한 라우팅 템플릿은 기본 출구를 바꿀 수 있고, 원격 DNS 설정은 이미 검증한 해석 경로를 대체할 수 있습니다. 운영 환경에서는 전역 규칙을 로컬 설정 프로필에 보관하고 구독은 서버만 제공하도록 하는 것이 좋습니다.

수동 서버도 격리가 필요합니다. 수동 객체를 별도 그룹에 넣고 명확한 메모를 사용하세요. 구독 객체인 것처럼 꾸미지 마세요. 수동 객체를 수정할 때는 먼저 복사한 뒤 편집하고 원본을 롤백용으로 남겨 두세요. 두 설정이 전송 매개변수만 다르다면 이름에 “WS 테스트”, “gRPC 테스트”처럼 차이를 적으세요. “보조 1”, “보조 2”처럼만 쓰지 마세요. 이런 세부 정보가 이후 로그 분석에 직접 영향을 줍니다.

출처 유형 권장 업데이트 방식 목록 전략 장애 시 조치
주 구독 개별 업데이트 후 표본 검사 일상 후보 유지 새로 고침을 중지하고 기존 캐시 사용
보조 구독 낮은 빈도로 업데이트 핵심 지역만 유지 임시 전환, 주 소스는 덮어쓰지 않음
수동 추가 필요할 때 편집 별도 그룹 복사 후 수정하고 원본 유지

제어 가능한 장애 전환 실행하기

전환하기 전에 문제가 현재 서버에 있는지, DNS나 로컬 연결 계층에 있는지 먼저 확인하세요. 보조 서버를 선택한 뒤 코어를 다시 불러오고 로그에서 활성 아웃바운드를 확인한 다음 동일한 대상에 접속 테스트를 수행합니다. 전환에 성공하면 원인을 기록하고 원본 객체를 즉시 삭제하지 마세요. 네트워크 경로가 복구된 뒤 비교 대상으로 다시 필요할 수 있습니다. 주 구독의 모든 객체가 실패하고 보조 소스가 정상이라면 주 소스가 공통으로 사용하는 프로토콜이나 전송 조건을 우선 점검하세요. 두 출처가 동시에 실패하면 시스템 프록시, TUN, DNS 및 로컬 네트워크 계층으로 돌아가 확인해야 합니다.

다중 구독 정리를 마친 뒤에는 1분 안에 네 가지 질문에 답할 수 있어야 합니다. 현재 서버는 어느 구독에서 왔는가, 업데이트가 실패하면 어느 보조 그룹을 사용하는가, 어떤 필터 규칙이 서버를 숨기는가, 전역 라우팅은 구독과 독립적인가입니다. 답을 찾기 위해 여전히 긴 목록을 뒤져야 한다면 그룹 이름이나 역할이 충분히 명확하지 않은 것입니다. 복잡한 라우팅 설정으로 넘어가기 전에 먼저 정리하세요.

라우팅 규칙 실전: 매칭 순서로 트래픽 출구 결정하기

인바운드에서 아웃바운드까지의 판정 과정 이해하기

라우팅 규칙은 이미 코어에 들어온 연결을 처리합니다. 앱은 시스템 프록시, TUN 또는 로컬 프록시 포트를 통해 인바운드로 들어오고, 코어는 도메인, 대상 IP, 포트, 네트워크 유형, 프로세스 또는 인바운드 태그를 읽은 뒤 규칙 순서에 따라 아웃바운드를 선택합니다. 라우팅은 아직 클라이언트에 들어오지 않은 트래픽을 연결할 수 없으며 잘못된 서버 매개변수도 수정하지 못합니다. 설정하기 전에 앱 요청이 코어 로그에 실제로 도착하는지 확인한 뒤 직결, 프록시 또는 차단 중 어느 경로로 보낼지 논의하세요.

규칙은 일반적으로 위에서 아래로 매칭되며, 일치하면 더 이상 다음 규칙으로 진행하지 않습니다. 구체적인 조건은 앞에 배치하고 포괄적인 조건은 뒤에 배치한 다음, 마지막에 기본 아웃바운드로 미매칭 트래픽을 처리하세요. 일반적인 기준선은 사설 주소 직결, 로컬 도메인과 IP 집합 직결, 명확히 프록시가 필요한 도메인은 프록시로 전송, 나머지는 현재 정책에 따라 기본 출구로 보내는 방식입니다. “모든 도메인 프록시”를 첫 번째 규칙에 넣으면 이후 직결 규칙은 실행되지 않습니다.

도메인 전략 선택하기

라우팅의 도메인 전략은 코어가 IP 규칙과 매칭하기 위해 도메인을 언제 IP로 해석할지 결정합니다. AsIs를 사용하면 도메인 요청을 우선 도메인 규칙으로 판단하고 라우팅 목적으로 적극 해석하지 않습니다. IPIfNonMatch를 사용하면 도메인 규칙이 일치하지 않을 때 해석한 뒤 IP 규칙을 시도합니다. IPOnDemand를 사용하면 이후에 IP 판단이 필요할 때 해석이 실행될 수 있습니다. 일반적인 설정은 IPIfNonMatch부터 시작하는 것이 좋습니다. 도메인 규칙과 IP 집합을 모두 활용할 수 있지만 DNS 설정이 안정적인 결과를 제공하는지 확인해야 합니다.

적극적인 해석은 라우팅과 DNS를 서로 의존하게 만듭니다. DNS가 불안정한 주소를 반환하거나 서로 다른 경로에 따라 다른 지역으로 할당하면 IP 규칙 결과도 바뀔 수 있습니다. 따라서 명확한 도메인 집합으로 표현할 수 있는 대상은 도메인 규칙을 우선 사용하고, 대상 주소를 기준으로 판단해야 할 때만 IP 규칙에 의존하세요. 로그의 규칙 결과가 예상과 다르면 원본 도메인, 해석된 IP 및 최종 아웃바운드 태그를 함께 확인해야 합니다.

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

도메인, IP, 포트 및 인바운드 조건 조합하기

같은 규칙 안의 서로 다른 필드는 일반적으로 “모두 충족”으로 처리되고, 같은 필드 안의 여러 값은 일반적으로 “하나라도 일치”로 처리됩니다. 예를 들어 network: tcp와 port: 80,443을 함께 쓰면 TCP의 두 포트만 처리한다는 뜻입니다. 도메인 배열에 여러 집합을 넣으면 어느 하나의 집합만 일치해도 됩니다. 서로 관련 없는 대상을 하나의 규칙에 억지로 넣지 말고, 용도를 명확히 적은 여러 규칙으로 나누는 편이 문제를 찾기 쉽습니다.

인바운드 태그는 서로 다른 로컬 진입점에 다른 정책을 적용할 때 적합합니다. 예를 들어 브라우저는 로컬 SOCKS 인바운드를 사용하고 업무용 프로그램은 다른 HTTP 인바운드를 사용하도록 하여 각각 프록시 또는 직결로 보낼 수 있습니다. 프로세스 규칙은 클라이언트, 코어 및 시스템 권한 지원에 의존하며 플랫폼마다 동작이 완전히 같지 않습니다. 따라서 세밀한 보완 수단으로 사용하고 유일한 분할 기준으로 삼지 마세요. 포트 규칙은 명확한 서비스에 적합하지만 최신 앱은 다른 포트나 QUIC를 사용할 수 있으므로 포트만으로 앱 유형을 추측하면 매칭을 놓치기 쉽습니다.

세 계층의 규칙 구조 만들기

첫 번째 계층은 루프백, LAN 및 사설 주소처럼 원격 프록시로 보내면 안 되는 로컬 대상을 처리합니다. 두 번째 계층은 특정 도메인 직결, 특정 도메인 프록시, 광고 또는 알려진 위험 대상 차단과 같은 업무 예외를 처리합니다. 세 번째 계층은 기본 출구를 정의합니다. 각 계층 안에서는 구체적인 조건부터 포괄적인 조건 순으로 배치하세요. 규칙을 변경한 뒤 직결, 프록시 및 기본 경로를 각각 아우르는 세 가지 테스트 대상을 사용해 현재 관심 있는 규칙 하나만 검증하지 않도록 하세요.

차단 규칙은 설명 가능하게 유지해야 합니다. 특정 앱이 비정상적으로 시작되면 서버 장애로 단정하지 말고 먼저 차단 규칙을 잠시 비활성화해 확인하세요. UDP 규칙도 신중하게 다뤄야 합니다. 모든 UDP를 차단하면 DNS, 실시간 통신 또는 QUIC 기반 연결에 영향을 줄 수 있습니다. 목적이 특정 도메인을 TCP로 폴백시키는 것이라면 해당 앱이나 코어의 전송 설정에서 처리하는 편이 우선입니다. LAN 접속은 사설 주소 직결과 TUN 우회 범위도 함께 확인하세요.

로그로 규칙 매칭 검증하기

검증할 때는 먼저 로그를 비우거나 시간 지점을 표시한 뒤 단일 요청을 발생시키세요. 요청이 어느 인바운드로 들어왔는지, 인식된 도메인 또는 IP가 무엇인지, 어떤 규칙이 매칭되었는지, 최종 아웃바운드가 무엇인지 확인합니다. 로그에 도메인 없이 IP만 표시된다면 앱이 직접 대상을 해석했을 수 있어 도메인 규칙이 바로 매칭되지 않습니다. 이때 TUN의 도메인 스니핑, FakeDNS 또는 신뢰할 수 있는 IP 규칙 추가를 고려할 수 있습니다. 규칙은 올바르게 매칭되었지만 연결에 실패한다면 문제는 해당 아웃바운드나 서버 계층에 있습니다.

라우팅 유지 관리의 핵심은 규칙 수가 아니라 각 규칙에 설명 가능한 목표, 안정적인 데이터 출처 및 명확한 폴백이 있는지입니다. 분기별 또는 구독 구조 변경 후에는 만료된 도메인, 중복 집합 및 영원히 매칭되지 않는 하위 규칙을 확인하세요. “일부 앱은 정상이고 일부 앱은 실패”할 때는 먼저 같은 인바운드로 들어오는지, 같은 DNS를 사용하는지, 같은 아웃바운드에 매칭되는지를 비교한 뒤 도움말 센터에서 해당 문제 해결 분기를 확인하세요.

DNS 설정 최적화: 해석 경로와 라우팅 기준 통일하기

한 번의 질의가 거치는 경로부터 명확히 그리기

DNS 문제는 서버 문제로 잘못 판단하기 쉽습니다. 도메인에 한 번 접속할 때 앱 자체 해석, 운영체제 해석, 클라이언트 내장 DNS 및 원격 해석 중 하나 이상을 거칠 수 있습니다. 브라우저에서 독립적인 암호화 DNS를 활성화하면 시스템 설정을 우회할 수 있고, TUN 연결 후에는 시스템 질의가 코어로 유입될 수 있습니다. FakeDNS는 로컬에서 합성 주소를 반환한 뒤 실제 해석을 지연시킵니다. 최적화하기 전에 누가 질의를 시작하는지, 어느 서버로 들어가는지, 결과가 어디에서 라우팅에 사용되는지 확인하세요.

기본 설정은 가능한 한 단일 주 경로를 구성해야 합니다. 일반 앱은 질의를 시스템에 넘기고, 시스템 질의는 클라이언트가 연결하며, 코어는 도메인 집합에 따라 로컬 또는 원격 DNS를 선택하고 연결과 라우팅이 함께 사용할 결과를 반환합니다. 앱이 직접 해석한 뒤 IP만 클라이언트에 전달하면 코어는 원본 도메인 정보를 잃어 도메인 분할 기능이 약해집니다. 이때는 앱 설정을 통일하거나 TUN 환경에서 스니핑과 FakeDNS를 사용해 도메인 연결을 복원해야 합니다.

도메인 집합으로 해석 서버 선택하기

DNS 분할과 트래픽 분할은 같은 방향을 유지해야 합니다. 직결할 로컬 도메인은 로컬에서 접근할 수 있는 DNS로 보내고, 프록시할 도메인은 프록시 아웃바운드를 통해 접근하는 원격 DNS로 보낼 수 있습니다. 이렇게 하면 해석 결과와 실제 출구가 일치하지 않는 문제를 줄일 수 있습니다. 모든 질의를 여러 서버에 동시에 보내 가장 빠른 응답을 채택하는 방식은 피하세요. 가장 빠른 응답이 라우팅 의도에 가장 적합하다는 보장은 없으며, 병렬 질의는 결과의 불확실성을 높입니다.

{
  "dns": {
    "queryStrategy": "UseIPv4",
    "servers": [
      {
        "address": "223.5.5.5",
        "domains": ["geosite:cn"],
        "expectIPs": ["geoip:cn"]
      },
      {
        "address": "https://1.1.1.1/dns-query",
        "domains": ["geosite:geolocation-!cn"]
      },
      "223.5.5.5"
    ]
  }
}

예시에서는 먼저 geosite:cn에 로컬 DNS를 지정하고 expectIPs로 반환 주소 범위를 제한합니다. 그 밖의 명확한 비로컬 도메인은 암호화 DNS로 보내고, 마지막 항목을 미매칭 질의의 폴백으로 사용합니다. 실제 환경에서는 현재 네트워크에서 안정적으로 접근할 수 있는 DNS를 선택하고 예시 주소를 그대로 유지하지 마세요. 원격 DNS를 프록시를 통해 접근해야 한다면, 해당 DNS의 도메인이나 IP를 자기 자신이 해석할 때 순환이 생기지 않는지도 확인해야 합니다.

질의 전략과 주소 계열 선택하기

UseIPv4는 IPv4 주소만 요청하므로 로컬 IPv6를 사용할 수 없거나 라우팅이 아직 완전하지 않은 환경에 적합합니다. UseIPv6는 IPv6만 요청하고, UseIP는 두 주소 계열을 모두 허용합니다. 선택 기준은 로컬 링크, 프록시 아웃바운드 및 대상 서비스가 모두 지원하는지에 따라야 합니다. 어느 한 계층이라도 IPv6를 안정적으로 전달하지 못하면 IPv6 반환을 강제할 때 “도메인은 해석되지만 연결이 시간 초과됨”이라는 현상이 나타날 수 있습니다. 반대로 네트워크와 아웃바운드가 모두 지원하는데 IPv6를 계속 비활성화하면 사용 가능한 경로를 잃게 됩니다.

판단 기준은 시스템에 IPv6 주소가 할당되었는지가 아니라 로컬 직결, 프록시 아웃바운드 및 DNS 반환을 각각 테스트하는 것입니다. 로그에서 접근할 수 없는 IPv6를 먼저 시도한 뒤 IPv4로 폴백한다면 페이지 첫 로딩이 느려질 수 있습니다. 먼저 UseIPv4를 임시로 사용해 확인한 다음 IPv6 라우팅을 보완하세요. 주소 계열과 도메인 분할을 동시에 변경하지 마세요. 무엇이 개선을 가져왔는지 알기 어려워집니다.

DNS 순환과 누출 경로 피하기

DNS 순환은 “DNS 서버의 도메인 자체를 해석하려면 다시 같은 DNS를 호출해야 하는” 상황에서 주로 발생합니다. 해결 방법은 해당 서버에 직접 사용할 수 있는 IP를 제공하거나, hosts로 시작 주소를 고정하거나, 별도의 부트스트랩 해석기를 설정하는 것입니다. 또 다른 순환 원인은 DNS 아웃바운드가 일반 프록시 인바운드로 다시 라우팅되어 DNS를 재호출하는 경우입니다. DNS 질의에 명확한 아웃바운드 태그를 부여하고 라우팅에서 우선 처리하면 경로를 단방향으로 유지할 수 있습니다.

{
  "dns": {
    "hosts": {
      "resolver.example": "192.0.2.53"
    },
    "servers": [
      {
        "address": "https://resolver.example/dns-query",
        "skipFallback": true
      }
    ]
  }
}

예시에 있는 예약 주소는 필드 관계를 설명하기 위한 것일 뿐입니다. 실제 설정에서는 사용 중인 해석 서비스가 명확히 제공하는 주소로 반드시 교체하세요. 누출 경로는 설정 목표를 기준으로 이해해야 합니다. 특정 도메인을 원격 해석으로 보낼 계획인데 앱 자체나 시스템의 다른 인터페이스가 직접 질의하면 경로가 이탈한 것입니다. 확인할 때는 클라이언트 DNS 로그와 시스템 네트워크 활동을 함께 관찰하고 웹 테스트 결과에만 의존하지 마세요.

캐시, 새로 고침 및 장애 분석

DNS를 변경한 뒤에도 기존 캐시가 결과에 계속 영향을 줄 수 있습니다. 먼저 클라이언트 코어를 다시 불러오고 테스트 앱을 닫았다가 다시 여세요. 필요하면 운영체제 캐시도 새로 고칩니다. Windows에서는 터미널에서 ipconfig /flushdns를 실행하고, systemd-resolved를 사용하는 Linux에서는 resolvectl flush-caches를 실행할 수 있습니다. macOS와 Android의 캐시 동작은 시스템 네트워크 상태에 따라 달라질 수 있으며, 네트워크 인터페이스를 전환하거나 클라이언트 연결을 다시 수립하면 업데이트가 발생하는 경우가 많습니다. 명령은 시스템 캐시만 정리하므로 브라우저 내부 캐시까지 반드시 삭제하는 것은 아닙니다.

ipconfig /flushdns

resolvectl flush-caches

문제 해결 순서는 고정해야 합니다. 먼저 명확한 DNS 도구로 질의가 반환되는지 확인하고, 반환된 주소 계열을 확인한 다음, 라우팅이 해당 주소를 어떻게 처리하는지 보고, 마지막으로 해당 아웃바운드 연결을 점검하세요. 하나의 도메인만 실패하면 도메인 규칙, 캐시 및 서버 응답을 확인합니다. 모든 도메인이 실패하지만 IP 직접 접속은 정상이면 DNS 인바운드, 서버 주소 및 라우팅 순환을 중점적으로 확인합니다. 도메인과 IP가 모두 실패하면 연결 방식과 아웃바운드 계층으로 돌아가세요.

TUN 모드: 시스템 프록시를 읽지 않는 앱 연결하기

TUN이 실제로 필요한지 판단하기

시스템 프록시는 프록시 설정을 읽는 앱에만 영향을 줍니다. 명령줄 도구, 일부 데스크톱 소프트웨어, 게임 및 자체 네트워크 스택을 사용하는 프로그램은 직접 연결을 수립할 수 있어 클라이언트 로그에 요청이 보이지 않을 수 있습니다. TUN 모드는 가상 네트워크 인터페이스를 통해 더 많은 시스템 트래픽을 연결하므로 통합 분할 라우팅이 필요한 환경에 적합합니다. 그러나 라우팅 테이블, DNS 가로채기, 권한 및 우회 규칙이라는 추가 변수가 생깁니다. 브라우저와 주요 데스크톱 소프트웨어가 시스템 프록시로 정상 작동한다면 “설정을 더 완전하게” 만들기 위해 TUN을 켤 필요는 없습니다.

활성화하기 전에 앞 장에서 설정한 기준선을 먼저 완료하세요. 서버가 정상인지, 라우팅 규칙을 설명할 수 있는지, DNS가 안정적으로 해석되는지 확인합니다. 가상 인터페이스를 만들거나 기본 라우팅을 변경하는 다른 소프트웨어를 끄고 기존 시스템 프록시 상태와 복구 방법을 기록하세요. TUN 활성화에 실패하면 먼저 클라이언트를 종료해 가상 인터페이스와 라우팅 테이블을 복구한 뒤 다시 조정하세요. 남아 있는 인터페이스에서 여러 구현을 연속으로 전환하지 마세요.

스택 구현과 기본 매개변수 선택하기

클라이언트에는 system, gVisor 또는 mixed와 같은 네트워크 스택 옵션이 있을 수 있습니다. system 스택은 운영체제 기능에 더 의존하며 일반적으로 성능 경로가 직접적입니다. gVisor는 사용자 공간 네트워크 스택을 사용하므로 시스템 스택과 호환성이 다를 수 있습니다. mixed는 TCP와 UDP를 조합해 처리합니다. 모든 환경에 최적인 선택은 없습니다. 먼저 클라이언트 기본값을 사용하고, 특정 앱 연결 실패, UDP 이상 또는 절전 모드 복귀 실패가 나타날 때만 항목별로 전환하면서 로그를 비교하세요.

MTU는 가상 인터페이스가 운반하는 패킷 크기를 결정합니다. 너무 크게 설정하면 복잡한 경로에서 단편화나 패킷 손실이 발생해 작은 페이지는 열리지만 큰 요청이 멈출 수 있습니다. 너무 작으면 패킷 수와 처리 비용이 늘어납니다. 명확한 근거가 없다면 기본값을 유지하세요. 확인이 필요하면 MTU를 단계적으로 낮추며 같은 대상을 테스트하고, 네트워크 스택과 DNS를 동시에 바꾸지 마세요. 엄격한 라우팅 옵션은 우회 트래픽을 줄일 수 있지만 로컬 네트워크 접속에도 영향을 줄 수 있으므로 우회 주소와 함께 사용해야 합니다.

플랫폼 주요 사전 조건 우선 확인할 항목 일반적인 복구 방법
Windows 가상 인터페이스 생성 허용 관리자 권한, 인터페이스 및 라우팅 테이블 코어를 종료하고 네트워크 인터페이스를 다시 활성화
macOS 네트워크 확장 권한 승인 시스템 권한, DNS 및 기본 라우팅 연결을 끊은 뒤 인터페이스 다시 설정
Android 로컬 가상 네트워크 생성 허용 시스템 권한, 배터리 절전 제한 클라이언트 연결을 끊고 다시 연결
Linux TUN 및 라우팅 관리 권한 보유 기기, 정책 라우팅, 방화벽 코어를 중지하고 남은 규칙 정리

LAN 및 예약 주소 우회 설정

TUN 연결 후 프린터, 네트워크 저장소, 라우터 관리 페이지 또는 개발 환경이 실수로 프록시로 전송될 수 있습니다. 먼저 루프백 주소, 사설 주소 및 링크 로컬 주소는 직결되도록 하고, LAN 검색에 필요한 UDP 트래픽이 포괄적인 차단 규칙에 걸리지 않는지 확인하세요. 일반적인 사설 범위에는 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16이 있지만 기업 네트워크에서는 다른 내부 주소를 사용할 수 있으므로 실제 라우팅 테이블을 기준으로 판단해야 합니다.

사설 주소 우회는 LAN 기기가 클라이언트 프록시 포트에 접근하도록 허용한다는 뜻이 아닙니다. LAN 공유는 별도의 인바운드 설정이며 활성화 여부와 수신 주소 및 방화벽 범위를 따로 결정해야 합니다. 로컬 기기에서만 사용할 경우 프록시 인바운드는 계속 루프백 주소에 바인딩하세요. 공유를 활성화한다면 먼저 로컬 네트워크를 신뢰할 수 있는지 확인한 뒤 접근 범위를 설정하세요. TUN 라우팅 우회는 인바운드 접근 제어를 대신할 수 없습니다.

DNS 가로채기와 도메인 식별 처리하기

TUN 모드에서 안정적인 도메인 분할을 구현하려면 보통 시스템 DNS 질의를 코어로 가져와야 합니다. 연결만 가로채고 DNS를 가로채지 않으면 앱이 시스템 외부에서 먼저 IP를 얻어 코어에는 IP만 전달될 수 있습니다. DNS 가로채기를 활성화한 뒤 질의가 클라이언트 내장 DNS로 들어오는지 확인하고, 클라이언트 자체의 해석 요청이 다시 가로채이지 않도록 하세요. 포트 53은 전통적인 DNS의 일반적인 진입점이지만 앱 자체의 암호화 DNS는 여전히 우회할 수 있으므로 앱 설정과 라우팅 계층에서 함께 처리해야 합니다.

스니핑은 일부 연결에서 대상 도메인을 복원할 수 있지만 모든 프로토콜에서 안정적이라고 볼 수는 없습니다. 활성화 후 대상 주소가 잘못 덮어써지지 않는지 확인하세요. 특히 사용자 지정 인증서, 내부 도메인 또는 특수 서비스 검색을 사용하는 앱에서 주의해야 합니다. 연결이 수립된 직후 끊기면 대상 덮어쓰기를 잠시 끄고 도메인 식별만 남겨 비교하세요. FakeDNS도 도메인 매핑을 유지하는 방법이며 TUN 환경에 적합하지만, 독립적인 주소 풀과 올바른 회수 정책이 필요하므로 다음 장에서 별도로 설명합니다.

현상에 따라 TUN 장애 위치 찾기

활성화 후 네트워크가 완전히 끊기면 먼저 코어가 정상적으로 시작되었는지, 가상 인터페이스가 생성되었는지, 기본 라우팅이 예상 위치를 가리키는지, DNS에 여전히 접근 가능한 경로가 있는지 확인하세요. LAN만 실패하면 사설 주소 직결과 엄격한 라우팅을 확인합니다. UDP 앱만 실패하면 네트워크 스택, UDP 라우팅 및 서버의 프로토콜 지원을 비교합니다. 절전 모드 복귀 후 실패하면 TUN 인터페이스를 다시 만들고 기존 라우팅이 남아 있는지 확인하세요. 클라이언트 설정 전체를 먼저 삭제하지 마세요. TUN 장애는 대개 연결 계층에 있습니다.

검증이 끝나면 브라우저, 원래 시스템 프록시를 읽지 않던 앱, LAN 리소스, DNS 질의 및 UDP 업무를 각각 테스트하세요. 다섯 가지 테스트의 경로를 모두 설명할 수 있어야 TUN이 안정되었다고 볼 수 있습니다. 특정 명령줄 프로그램 하나에만 프록시가 필요하다면 전체 시스템을 연결하는 것보다 해당 프로그램에 명확한 프록시 환경 변수를 설정하는 편이 관리하기 쉽습니다.

FakeDNS: 도메인 정보를 유지하고 실제 해석 지연하기

합성 주소의 역할 이해하기

FakeDNS는 도메인 질의를 받으면 실제 대상 주소를 즉시 앱에 전달하지 않고, 사전에 정한 주소 풀에서 합성 IP를 반환하면서 “합성 IP—원본 도메인” 매핑을 저장합니다. 앱은 이후 이 합성 IP에 연결하고, TUN 또는 투명 연결 계층이 연결을 코어로 되돌립니다. 코어는 매핑을 조회해 도메인을 복원한 다음 도메인 규칙에 따라 DNS와 아웃바운드를 선택합니다. 따라서 앱이 IP에만 연결하더라도 코어가 원본 도메인을 얻을 수 있어 도메인 분할이 더 안정적으로 작동합니다.

합성 주소는 원격 서버 주소가 아니며 일반 라우팅에서 공용 네트워크 대상으로 취급해서도 안 됩니다. 합성 주소는 로컬 연결 경로 안에서 매핑 인덱스로만 사용됩니다. 요청이 TUN을 우회해 네트워크로 직접 전송되면 합성 주소에 접근할 수 없습니다. 따라서 FakeDNS는 이후 연결을 가로챌 수 있는 연결 방식과 함께 사용해야 하며, 내장 DNS에서 FakeDNS 옵션만 켜는 것으로는 전체 흐름이 완성되지 않습니다.

독립적이고 충돌하지 않는 주소 풀 계획하기

주소 풀은 로컬 실제 네트워크, 기업 인트라넷, 컨테이너 네트워크 및 기존 가상 인터페이스가 사용하는 범위를 피해야 합니다. 설정 전에 시스템 라우팅 테이블을 확인하고 후보 네트워크가 실제 라우팅에 사용되지 않는지 확인하세요. 주소 풀이 너무 작으면 많은 도메인이 동시에 요청될 때 매핑이 자주 회수되고, 너무 크면 다른 네트워크 설계와 충돌할 수 있습니다. 일반적으로 클라이언트 기본 범위를 유지하는 것이 가장 안정적입니다. 충돌이 확인될 때만 변경하고 새 범위를 TUN 라우팅이 포함하는지도 함께 확인하세요.

{
  "dns": {
    "servers": [
      {
        "address": "fakedns",
        "domains": ["geosite:geolocation-!cn"]
      },
      "223.5.5.5"
    ],
    "queryStrategy": "UseIPv4"
  },
  "fakedns": [
    {
      "ipPool": "198.18.0.0/15",
      "poolSize": 65535
    }
  ]
}

198.18.0.0/15는 벤치마크 테스트 네트워크에 자주 사용되며 일부 클라이언트는 이를 합성 주소로 기본 사용합니다. 그래도 로컬 네트워크에 같은 범위의 라우팅이 있는지 확인해야 합니다. poolSize는 사용 가능한 매핑 수를 제어하며 주소 풀의 실제 용량을 초과해서는 안 됩니다. 설정 필드는 코어 계열과 클라이언트 생성 방식에 따라 달라질 수 있습니다. 그래픽 인터페이스를 사용할 때는 먼저 클라이언트가 구조를 생성하게 한 뒤 최종 코어 설정을 확인하세요. 예시 전체를 호환되지 않는 계층에 그대로 덮어쓰지 마세요.

FakeDNS를 사용할 도메인 결정하기

모든 질의에 합성 주소가 필요한 것은 아닙니다. 로컬 도메인, LAN 서비스, 프린터 검색 및 앱에 실제 IP를 반환해야 하는 도구는 보통 일반 DNS를 계속 사용해야 합니다. 도메인 기준으로 프록시할 공용 대상은 FakeDNS에 넣는 편이 적합합니다. 먼저 명확한 비로컬 도메인 집합에만 활성화하고 안정성을 확인한 뒤 범위를 넓히세요. 모든 질의를 FakeDNS로 보내면 로컬 서비스가 사용할 수 없는 합성 결과를 받을 수 있습니다.

제외 목록에는 LAN 접미사, 개발 환경 도메인 및 실제 주소에 의존하는 진단 도구를 포함해야 합니다. DNS 결과를 사용자에게 표시하거나 설정에 기록하거나 다른 기기에 전달하는 앱도 로컬 전용 합성 IP를 받기에 적합하지 않습니다. FakeDNS는 투명 연결 환경에서 도메인 연계를 해결하는 기능이지 범용 DNS 가속기가 아닙니다. 합성 결과를 LAN의 다른 기기로 전파해서도 안 됩니다.

스니핑, 라우팅 및 실제 해석 조정하기

FakeDNS가 원본 도메인을 복원하면 라우팅은 먼저 도메인 규칙으로 출구를 결정하고, 실제 DNS는 해당 출구와 같은 경로로 실행되어야 합니다. 도메인이 직결로 판정되면 직결 경로에 적합한 해석기를 사용하고, 프록시로 보내면 프록시 경로에 맞춰 설정한 해석기를 사용하세요. 그렇지 않으면 도메인을 성공적으로 복원해도 해당 출구에 적합하지 않은 주소를 얻을 수 있습니다. 로그에는 합성 매핑, 도메인 매칭 및 실제 대상 연결이 연속적으로 나타나야 합니다.

스니핑과 FakeDNS는 함께 사용할 수 있지만 역할은 다릅니다. FakeDNS는 질의 매핑으로 도메인을 복원하고, 스니핑은 연결 내용으로 도메인을 식별합니다. 두 기능을 동시에 켤 때는 대상 주소 덮어쓰기를 허용할지 명확히 정하세요. 같은 연결에서 도메인 판단이 충돌하면 먼저 스니핑 덮어쓰기를 끄고 FakeDNS만 남겨 비교하세요. 앱이 연결 가능한 DNS 질의를 전혀 보내지 않으면 FakeDNS는 매핑을 만들 수 없지만, 이때도 스니핑은 정보를 제공할 수 있습니다.

캐시와 매핑 만료 확인하기

앱, 시스템 및 클라이언트 모두 합성 결과를 캐시할 수 있습니다. 주소 풀을 변경하거나 FakeDNS를 끈 뒤에도 기존 합성 IP를 앱이 계속 사용하면 일부 도메인만 지속적으로 실패할 수 있습니다. TUN 연결을 끊고 코어를 다시 불러온 다음 시스템 DNS 캐시를 새로 고치고 테스트 앱을 재시작한 뒤 연결을 다시 설정하세요. 연결이 활성화된 상태에서 주소 풀을 자주 전환하지 마세요. 기존 매핑과 새 라우팅이 잠시 공존할 수 있습니다.

실행 시간이 오래 지난 뒤에만 실패하기 시작한다면 주소 풀 용량, 매핑 회수 및 앱의 DNS 캐시 주기를 확인하세요. 특정 도메인이 처음에는 정상이고 이후 비정상이라면 실제 DNS 반환이 바뀌었는지와 기존 연결이 만료된 매핑을 재사용했는지를 비교하세요. 모든 합성 주소에 연결할 수 없다면 원격 서버를 조정하기보다 TUN이 해당 네트워크 대역을 연결하고 있는지 확인해야 합니다.

최종 검증에는 일반 공용 도메인, 명확한 직결 도메인, LAN 도메인 및 앱 자체 해석이라는 네 가지 대상을 포함해야 합니다. 일반 공용 대상은 매핑을 생성하고 도메인 라우팅을 따라야 하며, 직결 및 LAN 대상은 제외 정책에 따라 실제 주소를 받아야 합니다. 자체 해석 앱은 연결 경로에 들어오는지 확인해야 합니다. 네 결과가 모두 설계와 일치할 때 FakeDNS가 불투명한 계층을 추가한 것이 아니라 도메인 분할을 실제로 개선했다고 볼 수 있습니다.

사용자 지정 아웃바운드: 태그, 체인 전달 및 최종 문제 해결

먼저 아웃바운드 역할과 태그 정의하기

아웃바운드는 라우팅 규칙의 최종 목적지입니다. 최소 설정에는 보통 프록시, 직결 및 차단이라는 세 가지 역할이 있으며 안정적인 태그 proxy, direct, block을 각각 사용합니다. 사용자 지정 아웃바운드는 특정 인터페이스 직결, 독립 DNS 아웃바운드 또는 체인 전달을 추가할 때 적합합니다. 하지만 아웃바운드를 하나 추가할 때마다 태그, 라우팅 참조 및 장애 폴백도 함께 관리해야 합니다. 태그는 대소문자를 구분하므로 이름을 바꾼 뒤 모든 규칙을 검색해 이전 이름을 계속 가리키지 않는지 확인하세요.

그래픽 클라이언트는 보통 현재 서버를 기준으로 주 프록시 아웃바운드를 생성합니다. 생성된 객체를 직접 수정하면 서버 전환이나 구독 업데이트 후 덮어써질 수 있습니다. 따라서 사용자 지정 부분은 클라이언트가 지원하는 추가 설정, 사전 설정 프로필 또는 사용자 지정 아웃바운드 영역에 넣어야 합니다. 먼저 클라이언트의 병합 순서를 확인하세요. 같은 이름의 필드가 덮어쓰기, 추가 또는 거부 중 어느 방식으로 처리되는지 알아야 합니다. 확인할 수 없다면 화면의 입력 조각만 보지 말고 최종 코어 설정을 내보내 실제 결과를 점검하세요.

{
  "outbounds": [
    {
      "tag": "direct",
      "protocol": "freedom",
      "settings": {
        "domainStrategy": "UseIP"
      }
    },
    {
      "tag": "block",
      "protocol": "blackhole",
      "settings": {
        "response": {
          "type": "none"
        }
      }
    }
  ]
}

직결 출구에 주소 계열 또는 인터페이스 지정하기

여러 네트워크 인터페이스가 있는 기기는 유선, 무선, 가상 네트워크 및 기업 네트워크에 동시에 연결될 수 있습니다. 기본 직결은 시스템 라우팅이 인터페이스를 선택하지만, 사용자 지정 직결 아웃바운드는 코어가 지원할 경우 송신 주소나 주소 계열을 지정해 특정 트래픽을 특정 로컬 인터페이스로 고정할 수 있습니다. 설정 전에 해당 주소가 장기간 유지되는지 확인하세요. 동적으로 할당되는 주소는 절전 모드, 재연결 또는 네트워크 전환 후 무효가 될 수 있습니다. 목적이 LAN 접속뿐이라면 시스템 라우팅과 사설 주소 직결을 우선 사용하고 인터페이스를 강제로 고정할 필요는 없습니다.

주소 계열을 지정할 때는 DNS 질의 전략과 일치시켜야 합니다. 직결 아웃바운드가 IPv4만 허용하는데 DNS가 IPv6를 반환하면 연결은 계속 실패합니다. 프록시 아웃바운드가 듀얼 스택을 지원한다고 해서 로컬 직결도 지원하는 것은 아닙니다. 문제를 해결할 때 DNS 결과, 라우팅 태그 및 아웃바운드가 실제로 다이얼한 주소를 각각 기록하세요. 여러 인터페이스 환경에서는 TUN이 만든 라우팅 우선순위도 확인해 사용자 지정 직결이 다시 TUN으로 들어가 순환하지 않도록 해야 합니다.

체인 전달의 적용 범위 이해하기

체인 전달은 하나의 프록시 아웃바운드가 다른 아웃바운드를 통해 연결을 수립하도록 합니다. 명확한 네트워크 토폴로지나 진입 제한에 사용할 수 있지만 핸드셰이크 계층, 지연 시간 및 장애 지점을 늘리므로 서버 필터링을 대신하는 용도로는 적합하지 않습니다. 체인을 설정하기 전에 앞단 아웃바운드와 최종 아웃바운드가 각각 독립적으로 정상 작동하는지 확인한 뒤 연결하세요. 어느 한 계층에서 DNS, 주소 계열, UDP 지원 또는 전송이 실패해도 최종 연결 실패로 나타납니다.

체인에는 순환이 없어야 합니다. 아웃바운드 A가 B를 통해 연결된다면 B가 다시 A를 통해 연결되어서는 안 됩니다. DNS 아웃바운드도 최종적으로 해당 DNS가 해석해야 하는 프록시에 의존해서는 안 됩니다. 각 계층에 proxy-entry, proxy-exit처럼 명확한 태그를 사용해야 로그에서 어느 단계에서 실패했는지 판단할 수 있습니다. 기본 라우팅은 최종 업무 출구만 가리켜야 하며, 앞단 아웃바운드는 전달 관계에서 호출하고 포괄적인 규칙이 직접 매칭하지 않도록 하세요.

독립 DNS 아웃바운드 만들기

코어가 DNS 아웃바운드를 지원하면 내부 DNS 질의를 전용 태그로 지정한 경로에 보낼 수 있습니다. 이를 통해 라우팅 규칙에서 DNS 트래픽과 일반 연결을 분리하고 순환을 줄일 수 있습니다. 일반적인 구조는 내장 DNS가 질의를 만들고 DNS 아웃바운드가 전송하며, 라우팅이 해당 인바운드 또는 프로토콜을 dns-out으로 우선 지정하는 방식입니다. 원격 해석기에 프록시 접속이 필요하다면 dns-out이 명확한 프록시 경로를 사용하도록 하고 기본 규칙의 추측에 의존하지 마세요.

{
  "outbounds": [
    {
      "tag": "dns-out",
      "protocol": "dns",
      "settings": {
        "address": "1.1.1.1",
        "port": 53,
        "network": "tcp"
      }
    }
  ],
  "routing": {
    "rules": [
      {
        "type": "field",
        "inboundTag": ["dns-in"],
        "outboundTag": "dns-out"
      }
    ]
  }
}

예시는 태그 관계를 설명하기 위한 것이며 모든 클라이언트가 같은 필드로 DNS 아웃바운드를 생성한다는 뜻은 아닙니다. 암호화 DNS를 사용할 때는 주소, 포트 및 전송을 코어가 지원하는 방식에 맞게 설정해야 합니다. 검증의 핵심은 질의가 하나의 인바운드와 하나의 아웃바운드만 거치고 일반 DNS 진입점으로 되돌아가지 않는지 확인하는 것입니다. 로그에 같은 도메인이 계속 반복되면 해석 순환을 우선 의심하세요.

계층별로 최종 문제 해결하기

복잡한 설정이 실패하면 요청 진입점에서 바깥쪽으로 계층별 확인을 진행하세요. 첫째, 앱 트래픽이 시스템 프록시 또는 TUN으로 들어오는지 확인합니다. 둘째, DNS가 사용 가능한 결과를 얻고 도메인 정보를 유지하는지 확인합니다. 셋째, 라우팅이 예상한 태그에 매칭되는지 확인합니다. 넷째, 해당 태그의 아웃바운드가 존재하고 매개변수가 유효한지 확인합니다. 다섯째, 마지막으로 원격 연결을 점검합니다. 각 단계에는 로그 근거가 필요합니다. 진입점과 라우팅을 건너뛰고 서버부터 바꾸면 현상만 일시적으로 달라질 수 있습니다.

오류는 범위에 따라 좁혀 볼 수 있습니다. 모든 앱이 실패하면 코어 시작, 연결 방식 또는 기본 아웃바운드 문제일 가능성이 큽니다. 특정 앱만 실패하면 프록시 방식, 프로토콜 및 DNS 동작을 비교하세요. 특정 도메인만 실패하면 도메인 규칙, 캐시 및 실제 해석을 확인합니다. UDP만 실패하면 네트워크 스택, 라우팅 및 아웃바운드 기능을 확인하고, LAN만 실패하면 사설 주소와 TUN 우회를 확인하세요. 단일 “복구 명령”을 외우기보다 현상을 설정 계층에 대응시키는 편이 더 안정적입니다.

배포 전 점검 목록

  1. 최소 작동 설정 하나와 안정적인 롤백용 서버 하나를 남겨 두세요.
  2. 구독 업데이트가 로컬 DNS, 라우팅 및 사용자 지정 아웃바운드를 덮어쓰지 않는지 확인하세요.
  3. 각 라우팅 규칙이 존재하는 아웃바운드 태그를 참조하고 기본 규칙이 마지막에 있는지 확인하세요.
  4. 직결, 프록시, 차단, DNS 및 LAN 경로를 각각 검증하세요.
  5. TUN을 활성화한 뒤 시스템 프록시를 읽지 않는 앱을 테스트하고 가상 인터페이스가 복구되는지 확인하세요.
  6. FakeDNS를 활성화한 뒤 주소 풀 충돌, 매핑 복원 및 제외 도메인을 확인하세요.
  7. 로그를 일상 수준으로 되돌리고 최종 설정을 내보낸 뒤 용도를 기록하세요.

설정을 완료했다고 해서 최종 결과를 영구적인 상태로 보아서는 안 됩니다. 구독 이름, 네트워크 인터페이스, 시스템 권한 및 업무 도메인은 계속 바뀌므로 동작에 뚜렷한 변화가 나타날 때 기준선 테스트를 다시 실행하세요. 클라이언트를 바꿔야 한다면 먼저 v2rayN, v2rayNG, v2flyNG 비교 평가를 확인하세요. 재설치가 필요하면 클라이언트 다운로드 페이지로 이동하고, 구체적인 로그 오류가 발생하면 런타임 로그 분석 절차와 함께 처리하세요. 규칙을 계속 늘리는 것보다 설정 계층, 안정적인 태그 및 되돌릴 수 있는 변경을 유지하는 편이 중요합니다.