구독 그룹 및 서버 필터링
구독 그룹은 서버 출처와 업데이트 범위를 관리하고, 서버 필터는 목록에 표시할 항목을 좁힙니다. 둘 다 트래픽을 분할하는 기능은 아닙니다. 한 그룹에 여러 서버를 넣을 수 있지만, 실제 연결은 현재 선택된 서버를 사용합니다. 그룹 탭을 바꿔도 활성 서버가 바뀌지 않을 수 있습니다. 이 차이를 이해하면 “다른 그룹의 목록이 보이니 연결도 바뀌었을 것”이라고 잘못 판단하는 일을 피할 수 있습니다.
출처를 추적할 수 있는 그룹 만들기
v2rayN의 ‘구독 그룹’ 메뉴에서 새 그룹을 만들고, 출처를 알아볼 수 있는 메모를 입력한 뒤 구독 주소 전체를 붙여 넣습니다. 주소에는 보통 접근 자격 증명이 포함되므로, 메모에는 출처나 용도만 적고 주소의 매개변수는 복사하지 마세요. 앞뒤 공백과 줄바꿈을 확인한 뒤 저장하고 해당 그룹만 업데이트합니다. 처음 업데이트할 때는 로그가 완료를 표시하는지 확인한 다음 목록에 항목이 있는지 살펴보세요. 자동 업데이트, 필터링, 일괄 삭제를 동시에 활성화하지 마세요.
그룹 이름은 ‘출처와 용도’를 함께 적는 방식이 좋습니다. 예를 들어 업무용 구독, 모바일 네트워크 예비용처럼 지정할 수 있습니다. 서버 별칭은 구독에서 가져오는 데이터이므로 다음 업데이트에서 바뀔 수 있습니다. 수동으로 이름을 바꿔도 장기적인 분류 기준으로 삼기 어렵습니다. 개인 메모를 남겨야 한다면 클라이언트가 지원하는 별도 메모 기능을 사용하거나 따로 기록하세요. 수동으로 가져온 서버는 별도 그룹으로 분류하면 구독 항목과 섞여 업데이트 결과를 잘못 판단하는 일을 줄일 수 있습니다.
업데이트할 때는 직접 연결로 가져오는지 프록시를 통해 가져오는지 구분해야 합니다. 기존 연결은 정상인데 직접 업데이트만 실패한다면 메뉴에서 프록시를 통한 구독 업데이트를 시도할 수 있습니다. 처음 설정하는 단계라 사용 가능한 연결이 없다면 프록시 업데이트가 반드시 해결책이 되지는 않습니다. 먼저 오류가 주소 해석 실패인지, 연결 시간 초과인지, 서버의 요청 거부인지 확인하세요. 반복 업데이트로 만료된 주소가 복구되지는 않으며, 오히려 출처 서버의 요청 제한에 걸릴 수 있습니다.
먼저 목록을 확인한 뒤 필터 적용하기
메인 창의 검색이나 필터는 대개 현재 표시되는 항목만 좁힙니다. 그룹 편집 화면의 서버 필터는 업데이트 시 유지할 항목에 영향을 줄 수도 있습니다. 실제 동작은 해당 설정의 설명을 확인하세요. 필터를 적용하기 전에 ‘전체’를 선택하고 검색 조건을 지운 뒤 대상 항목이 실제로 있는지 확인합니다. 그런 다음 해당 그룹에서 간단한 키워드 하나로 시험해 보세요. 조건을 여러 개 겹치면 어떤 조건이 서버를 제외했는지 판단하기 어렵습니다.
입력란에서 정규식을 지원한다고 명시한 경우, 세로줄은 선택 조건을, 괄호는 그룹을 나타내며 마침표는 기본적으로 임의의 문자 하나와 일치합니다. 아래 식은 별칭에 두 용도 중 하나가 포함된 항목을 찾는 필터 문법 예시입니다. 입력란이 일반 키워드만 지원한다면 정규식 기호를 넣지 말고 항목별로 검색하세요. 대소문자 구분 여부도 이미 알고 있는 항목으로 확인해야 합니다.
(업무용|예비용)구독을 업데이트한 뒤 목록이 비어 있다면 먼저 표시 필터를 지우고, 다음으로 그룹 필터를 확인한 뒤, 마지막으로 구독에서 반환된 내용을 확인하세요. 화면에 항목이 보이지 않는다고 원격 구독이 비어 있는 것은 아닙니다. 서버 목록의 유형, 주소, 포트, 전송 설정은 함께 보존해야 합니다. 별칭만으로 중복 여부를 판단하지 마세요. 이름이 같은 두 항목도 전송 방식이 다를 수 있습니다. 정리하기 전에 현재 활성 서버를 기록해 유일하게 사용할 수 있는 테스트 항목을 삭제하지 않도록 하세요.
업데이트 후 확인 및 복구
서버 필터는 설명 정보를 기준으로 목록을 좁힐 뿐, 연결 가능성을 확인하거나 가장 빠른 경로를 자동으로 선택하지 않습니다. 업데이트가 끝나면 남은 항목에서 ‘서버 실제 연결 지연 시간 테스트’ 또는 해당 속도 측정 메뉴를 실행한 뒤 서버를 직접 활성화하세요. 테스트 결과는 현재 네트워크, 테스트 대상, 서버 상태의 영향을 모두 받습니다. 같은 네트워크에서 반복 측정한 결과와 실제 서비스 접속을 기준으로 판단하세요.
업데이트로 기존 항목이 교체되면 클라이언트가 이전 활성 서버 선택을 유지하지 못할 수 있습니다. 이 경우 서버를 다시 선택하고 구성을 다시 불러온 다음 로그에서 코어가 정상적으로 시작됐는지 확인하세요. 이전 테스트 결과를 새 항목과 바로 비교하지 마세요. 별칭이 같아도 연결 매개변수가 그대로라는 보장은 없습니다. 테스트에 실패했다면 이미 사용 가능한 그룹으로 돌아가 기본 연결을 확인한 뒤 업데이트된 목록을 살펴보세요. 라우팅과 DNS 설정을 동시에 변경하지 마세요.
Android용 v2rayNG와 v2flyNG는 구독 메뉴, 그룹 표시 방식, 필터 기능이 서로 다를 수 있으므로 데스크톱 정규식 사용법을 그대로 적용하지 마세요. 먼저 출처별로 구독을 관리한 뒤 목록에서 구성을 선택할 수 있습니다. 구성을 내보내거나 화면을 공유하기 전에는 구독 주소, 서버 자격 증명, 계정을 식별할 수 있는 메모를 삭제하세요. 구독 링크는 계정 자격 증명처럼 관리해야 하며 공개 메모나 문의 화면에 올리지 않는 것이 좋습니다.
라우팅 규칙 실전
라우팅 규칙은 코어에 들어온 연결을 어떤 아웃바운드로 보낼지 결정하지만, 모든 앱의 트래픽을 자동으로 코어에 전달하지는 않습니다. 시스템 프록시는 프록시 설정을 따르는 앱에만 영향을 주고, TUN은 네트워크 계층에서 더 많은 연결을 받아들입니다. 따라서 브라우저에는 규칙이 적용되는데 다른 프로그램은 그대로라면, 먼저 그 프로그램이 프록시 경로에 들어오는지 확인한 뒤 규칙을 살펴보세요. 그렇지 않으면 트래픽 유입 범위 문제를 도메인 일치 오류로 오인할 수 있습니다.
프리셋으로 기본 설정 만들기
v2rayN의 라우팅 설정에서 현재 프리셋을 먼저 기록한 뒤 ‘중국 본토 우회(Whitelist)’, ‘블랙리스트(Blacklist)’, ‘전역(Global)’ 중 하나를 시작점으로 선택하세요. 프리셋 이름은 설정을 시작하는 메뉴일 뿐, 실제 동작은 규칙, 기본 아웃바운드, 규칙 데이터에 따라 달라집니다. 전역 모드도 로컬 주소 같은 모든 예외를 반드시 포함하는 것은 아닙니다. 정확히 확인하려면 모드 이름만으로 추측하지 말고 생성된 라우팅 설정을 살펴보세요.
규칙은 대개 순서대로 평가되며 일치하면 지정된 아웃바운드를 사용합니다. 먼저 LAN과 필요한 예외를 배치하고, 범위가 넓은 규칙을 뒤에 추가한 다음, 어떤 규칙에도 일치하지 않는 트래픽이 어디로 가는지 확인하세요. 한 규칙에 도메인, 포트, 네트워크 유형을 함께 입력하면 보통 모든 조건을 동시에 충족해야 한다는 뜻이지, 하나만 만족해도 된다는 뜻이 아닙니다. 도메인만으로 분기하려면 관련 없는 포트 조건을 추가하지 마세요.
다음은 Xray 형식의 라우팅 설정 조각입니다. 전체 구성에 direct와 proxy라는 아웃바운드가 이미 있다고 가정합니다. 첫 번째 규칙은 사설 주소를 직접 연결하고, 두 번째 규칙은 지정한 도메인과 하위 도메인을 프록시로 보냅니다. 예시 도메인은 문법 설명용이므로 실제 업무 도메인으로 바꿔야 합니다. 기본 아웃바운드와 연결 자격 증명은 정의되어 있지 않으므로 이 조각만으로 실행할 수 없습니다.
{
"routing": {
"domainStrategy": "AsIs",
"rules": [
{
"type": "field",
"ip": ["geoip:private"],
"outboundTag": "direct"
},
{
"type": "field",
"domain": ["domain:example.com"],
"outboundTag": "proxy"
}
]
}
}도메인, 주소 및 규칙 데이터
full:은 도메인 전체와 정확히 일치시킬 때, domain:은 지정한 도메인과 하위 도메인을 포함할 때 사용합니다. geosite:는 도메인 모음을, geoip:는 주소 모음을 참조합니다. 일반 문자열을 그대로 입력하면 키워드 방식으로 일치할 수 있어 예상보다 넓은 범위가 선택될 수 있습니다. 특정 서비스에만 예외를 적용하려면 전체 도메인을 우선 사용하고, 하위 도메인까지 포함해야 할 때만 도메인 접미사 방식을 사용해 다른 사이트가 잘못 선택될 가능성을 줄이세요.
도메인 규칙을 적용하려면 코어가 대상 도메인을 알아야 합니다. 앱이 프록시로 도메인을 전달하면 보통 그대로 일치시킬 수 있지만, 앱이 먼저 DNS 조회를 한 뒤 주소만 전달하면 도메인 스니핑이나 다른 도메인 매핑 기능이 필요할 수 있습니다. 스니핑으로 모든 프로토콜의 도메인을 복원할 수 있는 것은 아닙니다. 같은 사이트가 앱마다 다른 규칙에 걸린다면 먼저 로그의 대상 형식을 비교하세요. 한쪽은 도메인이고 다른 쪽은 주소일 수 있으므로 규칙 모음을 먼저 확대하지 마세요.
AsIs는 라우팅 일치를 위해 대상 도메인을 적극적으로 조회하지 않습니다. 다른 도메인 정책은 규칙에 일치하지 않거나 주소 규칙이 필요한 경우 조회를 시작할 수 있으므로, 구체적인 동작은 코어 문서에서 확인하세요. 조회된 주소는 캐시와 네트워크 위치의 영향도 받습니다. 따라서 주소 기준으로 바꾸는 것만으로 안정성이 높아진다고 볼 수 없습니다. 도메인이 명확한 서비스에는 도메인 규칙을 사용하고, 대상 네트워크 범위를 기준으로 처리해야 할 때만 주소 조건을 추가하세요.
규칙 데이터 파일과 규칙 문법은 서로 맞아야 합니다. 클라이언트에서 제공하는 업데이트 메뉴로 필요한 리소스를 갱신할 수 있지만, 업데이트 후에는 로그에서 정상적으로 불러왔는지 확인해야 합니다. 모음 이름이 없거나 리소스 파일을 읽지 못하거나 잘못된 코어를 선택하면 구성을 시작하지 못할 수 있습니다. 다른 코어의 규칙 파일 이름만 바꿔 사용하지 마세요. 모음 업데이트와 자주 쓰는 문법은 GeoIP 및 GeoSite 규칙 데이터 안내에서 확인할 수 있습니다.
로그와 실제 동작으로 확인하기
변경 후 구성을 다시 불러오고 대상 사이트 하나로 확인한 다음, 접속 로그의 대상, 일치한 규칙, 아웃바운드 태그를 살펴보세요. 브라우저의 기존 장기 연결은 이전 경로를 계속 사용할 수 있으므로 관련 탭을 닫거나 앱을 다시 시작한 뒤 테스트하세요. 한 번에 규칙 하나만 변경합니다. 규칙 데이터 업데이트, 서버 변경, DNS 설정 변경을 동시에 하면 문제가 해결돼도 무엇이 효과가 있었는지 알 수 없습니다.
로컬 프린터, 파일 공유, 인트라넷 관리 페이지에 접속할 수 없다면 먼저 사설 주소가 광범위한 프록시 규칙보다 앞에서 직접 연결되는지 확인하세요. 이어서 다른 프록시 계층이 앱의 연결을 가로채는지 살펴보세요. 내부 DNS를 사용하는 환경이라면 DNS가 인트라넷 주소를 반환하는지도 확인해야 합니다. 라우팅이 맞아도 DNS가 잘못되면 엉뚱한 대상에 연결됩니다. 따라서 라우팅과 다음 장의 DNS를 함께 확인하되, 변경은 단계별로 진행해야 합니다.
DNS 설정 최적화
DNS 설정에서는 세 가지를 먼저 확인해야 합니다. 누가 조회를 시작하는지, 조회가 어떤 경로를 거치는지, 결과를 어디에서 캐시하는지입니다. 시스템 리졸버, 브라우저의 보안 DNS, 프록시 코어의 내장 리졸버가 동시에 작동할 수 있습니다. 클라이언트에서 DNS 주소만 바꿔도 모든 앱이 그 주소를 사용하게 되는 것은 아닙니다. 시간 초과, 결과 불일치, 인트라넷 도메인 오류를 해결하기 전에 요청 경로를 정리해 불필요하게 DNS 서버를 늘리지 마세요.
DNS 조회가 이루어지는 위치 확인
프록시로 도메인을 전달하는 앱은 조회를 프록시 경로에 맡길 수 있습니다. 먼저 로컬에서 DNS 조회를 한 뒤 주소로 연결하는 앱은 코어에 들어오기 전에 이미 조회를 마친 상태입니다. TUN 모드에서는 DNS 가로채기로 시스템 조회를 코어에 전달할 수도 있습니다. 브라우저에서 별도로 암호화 DNS를 켰다면 또 다른 경로가 생깁니다. 브라우저와 명령줄의 결과가 다르면 어느 한쪽이 잘못된 서버를 쓴다고 단정하지 말고 각자의 DNS 설정을 확인하세요.
먼저 클라이언트 기본 DNS 설정을 유지한 채 연결 가능한 서버로 기준 상태를 확인하고, 필요에 따라 한 가지씩 변경하세요. 예를 들어 인트라넷 이름을 조직 내부 리졸버만 인식한다면 그 조회 경로를 유지해야 합니다. 일반 공용 인터넷 조회에는 연결 가능한 DNS 서비스를 사용할 수 있습니다. 공용 DNS에 접근할 수 있는 조건은 네트워크마다 다르므로 모든 환경에 맞는 단일 주소는 없습니다. 목표는 DNS 항목을 늘리는 것이 아니라 올바른 결과와 안정적인 경로를 확보하는 것입니다.
다음은 Xray 내장 DNS의 최소 필드 예시로, 서버 목록과 결과 유형만 보여줍니다. DNS 가로채기 규칙은 없으며 시스템 조회가 이 리졸버로 전달된다고 보장하지 않습니다. 숫자 주소를 사용하면 DNS 서버 자체의 도메인을 먼저 조회해야 하는 문제를 피할 수 있지만, 조회가 직접 연결되는지 프록시를 거치는지는 라우팅과 코어 동작을 함께 확인해야 합니다. 현재 네트워크에서 연결 가능성을 확인한 뒤 사용하세요.
{
"dns": {
"servers": ["1.1.1.1"],
"queryStrategy": "UseIP"
}
}도메인별 DNS 및 부트스트랩 조회
인트라넷 도메인, 공용 서비스 도메인, 프록시 서버 주소에는 서로 다른 DNS 정책이 필요할 수 있습니다. 인트라넷 도메인을 공용 DNS에 보내면 예상한 결과를 얻지 못하는 경우가 많습니다. 프록시 서버 주소를 아직 연결되지 않은 프록시로만 조회할 수 있다면 시작 단계에서 의존성이 생깁니다. 먼저 서버 주소를 조회하는 부트스트랩 경로를 독립적으로 사용할 수 있게 한 뒤 일반 트래픽의 DNS 분기를 설정하세요. 네트워크를 바꾼 뒤에는 특히 이 시작 경로를 다시 확인해야 합니다.
도메인을 사용하는 암호화 DNS 서비스를 이용하려면 먼저 서비스 도메인에 해당하는 주소를 알아야 합니다. 이 단계가 부트스트랩 조회입니다. 부트스트랩 조회마저 아직 사용할 수 없는 동일 서비스에 맡기면 순환 대기가 발생할 수 있습니다. 일부 클라이언트는 별도의 부트스트랩 항목을 제공하고, 일부는 코어나 시스템에서 처리하므로 같은 필드를 모든 환경에 적용할 수는 없습니다. 설정을 저장한 뒤 로그에서 ‘리졸버 도메인을 조회할 수 없음’과 ‘대상 서비스 도메인 조회 실패’를 구분하세요. 두 오류는 해결해야 할 위치가 다릅니다.
DNS 규칙과 트래픽 라우팅은 서로 맞아야 합니다. 직접 연결할 서비스가 현재 출구에서 멀리 떨어진 위치의 DNS를 사용하면 적절하지 않은 CDN 주소를 받을 수 있습니다. 프록시로 접속할 서비스도 DNS 조회 위치에 따라 서비스 지역 판정이 달라질 수 있습니다. 반드시 더 빠르거나 느린 경로가 있는 것은 아닙니다. 한 번의 DNS 응답 시간만 보지 말고 동일한 서비스의 연결 수립, 페이지 리소스 로딩, 지속적인 접속 상태를 비교하세요.
IPv6 사용 여부는 실제 네트워크 경로를 기준으로 결정해야 합니다. 시스템에 IPv6 주소가 있다고 해서 대상 서버까지 IPv6로 연결할 수 있는 것은 아닙니다. 그렇다고 IPv6를 모두 비활성화하는 것이 일반적인 최적화 방법도 아닙니다. 로그에 도달할 수 없는 주소 유형으로 계속 연결을 시도하는 것이 확인되면 DNS 응답 정책이나 아웃바운드 정책을 조정하세요. 먼저 시스템 라우팅과 네트워크 지원 여부를 확인해 DNS 결과만 숨긴 뒤 앱이 별도로 조회해 다른 주소 유형을 선택하는 상황을 피하세요.
캐시 및 문제 해결
DNS 결과는 시스템, 브라우저, 코어에 각각 캐시될 수 있습니다. 설정을 바꾼 뒤 관련 앱과 코어를 다시 시작하고 동일한 대상을 재시험하세요. 필요한 경우 시스템에서 제공하는 캐시 삭제 방법을 사용합니다. 명령줄 조회 결과는 해당 명령이 사용한 경로만 보여주며 브라우저나 프록시를 통한 요청의 결과와 다를 수 있습니다. 로그를 비교할 때 대상 도메인과 테스트 시간을 기록하고 서로 다른 계층의 캐시 결과를 섞어 판단하지 마세요.
‘도메인으로는 접속 실패, 주소로는 접속 성공’이라는 결과는 DNS를 확인해 볼 단서일 뿐, DNS 장애를 확정하는 근거는 아닙니다. 주소로 HTTPS에 접속하면 인증서 이름, 요청 호스트, 서버 라우팅이 달라질 수 있어 많은 사이트가 이런 테스트를 허용하지 않습니다. 더 신뢰할 수 있는 순서는 조회 성공 여부와 응답의 적절성을 확인하고, 대상 포트에 연결할 수 있는지 살펴본 뒤 앱 프로토콜 계층의 오류를 확인하는 것입니다. 오류 유형도 그대로 기록하세요.
라우팅 정책을 주소 일치 방식으로 바꾸면 로컬 DNS 조회에 의존하게 되어 이전에 드러나지 않던 DNS 문제가 바로 나타날 수 있습니다. 이때는 기존 도메인 정책을 먼저 복원해 기본 연결을 확인한 뒤 DNS만 따로 해결하세요. 증상을 가리기 위해 FakeDNS를 동시에 켜지 마세요. FakeDNS는 별도의 매핑과 가로채기 조건에 의존하며 적용 범위는 뒤에서 설명합니다. 시작 및 연결 오류는 FAQ의 유형별 안내를 참고해 추가로 확인할 수 있습니다.
TUN 모드 설정
TUN 모드는 가상 네트워크 인터페이스와 라우팅을 이용해 더 많은 앱의 연결을 프록시로 전달합니다. 시스템 프록시를 따르지 않는 프로그램에 유용합니다. 바뀌는 것은 트래픽이 들어오는 범위이지 연결 품질이 자동으로 좋아지는 것은 아니며, 모든 트래픽이 하나의 출구를 사용해야 한다는 뜻도 아닙니다. TUN으로 들어온 뒤 직접 연결할지, 프록시로 보낼지, 차단할지는 여전히 라우팅이 결정합니다. 활성화하기 전에 일반 프록시 방식으로 연결이 되는지 확인해 서버 문제와 네트워크 가로채기 문제를 함께 다루지 않도록 하세요.
권한, 코어 및 트래픽 가로채기 범위
v2rayN 메인 창에서 ‘TUN 모드 사용’을 켜기 전에 클라이언트에 필요한 권한이 있는지 확인하세요. Windows에서는 권한 상승이나 클라이언트가 지원하는 서비스 방식으로 실행해야 할 수 있습니다. 다른 데스크톱 운영체제에서도 네트워크 인터페이스 생성과 라우팅 변경 권한이 필요할 수 있습니다. 현재 설치 방식에 맞는 권한을 부여하고, 매번 높은 권한으로 실행하는 것을 장기적인 문제 해결 방법으로 삼지 마세요. 로그에서 인터페이스와 라우팅이 정상적으로 설정됐는지 확인할 수 있어야 합니다.
데스크톱 클라이언트는 TUN에 서로 다른 실행 구성 요소를 사용할 수 있으므로 실제 필드가 일반 프록시 코어와 다를 수 있습니다. 활성화한 뒤 실행 로그와 생성된 구성을 확인해 어떤 구성 요소가 트래픽 유입과 아웃바운드를 담당하는지 파악하세요. Xray JSON 조각을 다른 TUN 설정 형식에 그대로 붙여 넣지 마세요. 화면에서 정상적으로 전환되는데 로그에 알 수 없는 필드가 표시된다면 기본 템플릿으로 복원한 뒤 구성과 실행 구성 요소가 서로 맞는지 확인하세요.
| 환경 | 트래픽 유입 방식 | 우선 확인할 항목 |
|---|---|---|
| v2rayN 데스크톱 | 클라이언트의 TUN 가로채기 | 권한, 가상 인터페이스, 시스템 라우팅 및 DNS |
| v2rayNG Android | 시스템 VPN 서비스 | 연결 권한, 앱별 설정, 백그라운드 제한 |
| v2flyNG Android | 시스템 VPN 서비스 | 시스템 VPN 서비스 |
Android 클라이언트는 대개 시스템 VPN 서비스를 이용해 앱 트래픽을 받아들이며, 처음 연결할 때 시스템 권한을 확인해야 합니다. 앱별 설정에서 포함하거나 제외할 앱을 지정하므로 목록이 ‘선택한 앱을 프록시로 연결’하는 방식인지 ‘선택한 앱을 우회’하는 방식인지 확인하세요. 이는 데스크톱의 ‘TUN 모드 사용’ 옵션을 그대로 옮긴 기능이 아닙니다. 시스템 VPN 서비스를 사용하는 다른 도구와 함께 실행하면 서로 충돌하거나 연결이 교체될 수 있습니다.
루프를 먼저 해결한 뒤 분기 확인하기
TUN이 설정되면 프록시 프로세스가 서버에 연결하는 트래픽은 TUN 가로채기를 우회할 수 있어야 합니다. 그렇지 않으면 연결 루프가 발생합니다. 클라이언트가 관련 라우팅이나 프로세스 제외를 자동 처리하는 경우가 많지만, 사용자 지정 템플릿, 추가 네트워크 카드, 다른 터널이 이 조건을 깨뜨릴 수 있습니다. TUN을 켠 뒤 서버 연결도 안 되거나 로그에서 반복 시도가 발생하거나 모든 요청이 시간 초과되는 것이 흔한 증상입니다. 먼저 TUN을 끄고 기본 연결을 복구한 뒤 출구 라우팅을 확인하세요. 프록시 적용 범위를 계속 넓히지 마세요.
LAN 접속에는 라우팅과 DNS를 모두 확인해야 합니다. 공용 인터넷에는 접속되지만 프린터나 내부 서비스가 열리지 않는다면 사설 주소가 직접 연결되는지, 내부 도메인이 올바른 DNS를 사용하는지, 더 넓은 가로채기 규칙이 LAN 라우팅을 덮어쓰는지 확인하세요. 테스트를 위해 로컬 네트워크 전체를 원격 프록시로 보내지 마세요. 원격 사설 네트워크에 접속해야 한다면 로컬의 같은 주소 대역과 구분해 주소 범위가 겹쳐 대상이 모호해지는 상황을 피해야 합니다.
첫 확인은 세 단계로 진행할 수 있습니다. 먼저 정상 작동이 확인된 웹페이지에 접속하고, 다음으로 원래 시스템 프록시를 따르지 않던 앱을 테스트한 뒤, 마지막으로 LAN과 내부 도메인을 확인하세요. 작업 표시줄 아이콘만 바뀌었는지 보지 말고 실제 트래픽이 클라이언트에 들어오는지도 살펴보세요. 시스템 프록시를 함께 켠 상태라면 브라우저가 이전 경로를 사용해 성공했을 수 있습니다. 기존 상태를 기록한 뒤 시스템 프록시를 잠시 끄고 TUN이 실제로 작동하는지 따로 확인할 수 있습니다.
UDP, 경로 MTU 및 종료 후 복구
앱 트래픽이 TUN에 들어간다고 현재 서버를 통해 모든 프로토콜이 통과되는 것은 아닙니다. 음성 통화, 게임, 일부 전송에는 UDP가 사용되므로 클라이언트, 코어, 서버, 네트워크 경로가 모두 이를 지원해야 합니다. 웹페이지는 정상인데 실시간 통신이 실패한다면 UDP 지원 여부와 로그를 확인하세요. 웹 테스트 결과만으로 판단할 수 없습니다. 일부 앱은 서로 다른 전송 프로토콜을 선택할 수도 있으므로 테스트 중 설정을 동일하게 유지해 프로토콜 전환의 영향을 라우팅 문제로 오인하지 마세요.
일부 사이트에서 연결은 되지만 대용량 전송이 멈춘다면 경로 MTU뿐 아니라 패킷 손실, 프로토콜, 서버 문제가 원인일 수 있습니다. 정해진 MTU 값을 그대로 적용하지 마세요. 먼저 사용 가능한 것으로 확인된 다른 서버로 바꿔 TUN을 끈 상태와 비교한 뒤 로그와 네트워크 진단으로 범위를 좁히세요. 패킷 분할이나 경로 문제라는 근거가 있을 때만 관련 매개변수를 조정하고 기존 값을 기록하세요. 그렇지 않으면 추적하기 어려운 변수를 하나 더 만들 뿐입니다.
종료할 때는 먼저 TUN을 끄고 클라이언트를 종료한 뒤 일반 네트워크와 시스템 DNS가 복구됐는지 확인하세요. 절전 모드에서 깨어나거나 네트워크를 전환한 뒤 문제가 발생했다면 구성을 바로 수정하기보다 트래픽 가로채기를 다시 설정하는 편이 적절할 수 있습니다. 복구되지 않으면 남아 있는 인터페이스, 라우팅 또는 다른 네트워크 가로채기 서비스를 확인하세요. 용도를 모른 채 시스템 라우팅을 일괄 삭제하지 마세요. 회사 네트워크에서는 관리 정책이 라우팅을 유지할 수 있습니다.
Android에서 백그라운드 연결이 끊긴다면 데스크톱 네트워크 복구 명령을 그대로 적용하지 말고 배터리 최적화, 백그라운드 실행 제한, 앱별 프록시 설정을 확인하세요. 연결 유지와 배터리 절약 사이에서 실제 사용 환경에 맞게 선택해야 합니다. 자세한 내용은 v2rayNG 백그라운드 연결 및 배터리 사용 문제 해결을 참고하세요. 테스트를 마친 뒤에는 안정적인 모드 하나만 유지해 여러 트래픽 가로채기 도구가 부팅과 함께 실행되지 않도록 하세요.
FakeDNS 매핑 원리
FakeDNS는 합성 주소로 도메인을 임시 대체하고, 이후 연결이 코어에 들어오면 도메인을 복원해 라우팅에 필요한 도메인 정보를 유지합니다. 합성 주소는 원격 서버의 실제 주소도 아니고 별도의 암호화 프로토콜도 아닙니다. 앱이 먼저 DNS를 조회한 다음 주소로만 연결하지만 프록시는 도메인 기준 규칙을 적용해야 하는 경우에 유용합니다. 일반 DNS와 라우팅으로 이미 원하는 결과를 얻고 있다면 설정 항목을 늘리기 위해 켤 필요는 없습니다.
DNS 조회와 연결이 하나의 흐름으로 이어져야 합니다
전체 흐름은 앱이 도메인을 조회하고, 조회 요청이 FakeDNS로 전달되며, 앱이 합성 주소를 받은 뒤 그 주소에 연결하고, 연결이 매핑 정보를 가진 코어로 다시 전달되는 순서입니다. 어느 단계든 빠지면 ‘DNS 응답은 받았지만 연결할 수 없는’ 상황이 발생할 수 있습니다. 특히 앱의 DNS 조회가 가로채기를 우회하지 않는지, 합성 주소 범위가 직접 연결 규칙에 먼저 허용되지 않는지 확인하세요. 주소 풀만 설정하고 조회 경로를 연결하지 않으면 자동으로 작동하지 않습니다.
다음은 합성 주소 풀, DNS 서버 선택, 인바운드 스니핑의 관계를 보여주는 Xray 형식의 필드 조각입니다. 198.18.0.0/15는 예약된 벤치마크 주소 공간이며 공용 서버 주소가 아닙니다. 예시는 IPv4 매핑만 설명하며 전체 인바운드, 아웃바운드, DNS 전달 규칙은 포함하지 않습니다. 실제로 어디에 병합할지는 현재 클라이언트가 생성하는 구성 구조를 기준으로 해야 합니다.
{
"fakedns": [
{
"ipPool": "198.18.0.0/15",
"poolSize": 65535
}
],
"dns": {
"servers": ["fakedns"]
}
}매핑을 복원할 인바운드에도 FakeDNS를 인식할 수 있는 스니핑 설정이 필요합니다. 아래 객체는 인바운드 내부의 sniffing 필드 예시이며 최상위 구성 항목이 아닙니다. 이러한 필드를 지원하지 않거나 다른 구성 형식을 사용하는 실행 구성 요소에서는 그대로 사용할 수 없습니다. 먼저 코어가 지원하는지 확인한 다음 클라이언트가 이미 동일한 설정을 자동으로 생성했는지 살펴 중복으로 추가하지 않도록 하세요.
{
"sniffing": {
"enabled": true,
"destOverride": ["fakedns"]
}
}주소 풀, 캐시 및 호환성
ipPool은 할당할 합성 주소 범위를 지정하고, poolSize는 매핑 용량을 설정합니다. 주소 풀은 실제 네트워크와 다른 터널의 주소 범위와 구분해야 하며, 사용 중인 LAN 대역을 임의로 대체해 사용해서는 안 됩니다. 기본 예약 대역도 충돌이 절대 발생하지 않는 것은 아닙니다. 테스트 환경이나 다른 네트워크 제품이 같은 대역을 사용할 수 있습니다. 충돌이 발생하면 주소의 소유와 라우팅을 먼저 확인하세요. 필드 하나만 바꾸고 전체 경로가 변경됐다고 판단하지 마세요.
매핑은 해당 코어가 실행되는 동안에만 의미가 있습니다. 코어를 재시작한 뒤에도 앱이 이전 합성 주소를 캐시하고 있으면 새 인스턴스에는 해당 도메인 기록이 없어 DNS 조회는 정상처럼 보이지만 이후 연결이 실패할 수 있습니다. 모드를 전환할 때는 영향을 받는 앱을 다시 시작하고 필요한 DNS 캐시를 지운 뒤 새로운 도메인 조회부터 테스트하세요. 백그라운드에서 오래 실행되는 앱은 만료된 매핑을 계속 보유하기 쉽습니다.
모든 앱이 합성 주소를 사용할 수 있는 것은 아닙니다. 공용 인터넷에서 라우팅 가능한 주소인지 직접 확인하는 프로그램도 있고, 결과를 다른 프로세스나 기기에 넘기는 프로그램도 있으며, 숫자 주소를 고정해서 사용하는 프로그램도 있습니다. 앞의 두 경우에는 매핑 흐름이 끊길 수 있고, 마지막 경우에는 복원할 도메인이 애초에 없습니다. 특정 앱에서만 문제가 생기면 주소 풀을 계속 넓히기보다 해당 앱에 일반 DNS를 사용하거나 트래픽 유입 방식을 조정하세요. 용량을 늘려도 호환성 문제는 해결되지 않습니다.
브라우저가 암호화 DNS를 직접 사용하면 조회가 로컬 FakeDNS를 통과하지 않아 해당 매핑을 얻지 못할 수 있습니다. 반대로 FakeDNS 결과를 동일한 가로채기 경로를 사용하지 않는 다른 기기와 공유해도 보통 사용할 수 없습니다. FakeDNS를 활성화한 기기의 DNS 응답을 일반 LAN DNS 서비스처럼 배포하지 마세요. 합성 주소를 복사해 정적 서버 설정에 넣는 것도 피해야 합니다.
라우팅, DNS 및 복구 설정과 함께 사용하기
FakeDNS가 도메인을 복원한 뒤에도 라우팅은 올바른 아웃바운드를 선택해야 합니다. 실제 연결을 수립할 때 실제 주소를 추가로 조회하거나 도메인을 원격으로 전달해야 할 수도 있습니다. FakeDNS가 모든 일반 DNS 조회를 없애는 것은 아닙니다. 특히 프록시 서버 주소는 사용할 수 있는 부트스트랩 조회 경로를 유지해야 합니다. 서버까지 이미 실행 중인 터널에서만 처리할 수 있는 합성 주소를 받으면 시작 단계에서 의존성이 생길 수 있습니다.
확인할 때는 먼저 앱을 닫고 매핑을 지원하는 구성을 시작한 다음 앱을 열어 명확한 도메인 하나에 접속하세요. DNS 조회가 FakeDNS에 들어오는지, 연결 대상이 주소 풀에 포함되는지, 코어가 도메인을 복원해 예상한 규칙과 일치시키는지 확인합니다. 첫 단계에서 조회가 전달되지 않으면 DNS 가로채기를 살펴보세요. 합성 주소는 반환됐지만 연결이 들어오지 않으면 라우팅을 확인하세요. 연결은 들어왔지만 도메인을 복원하지 못하면 스니핑과 매핑 상태를 확인합니다.
일반 DNS를 복원하고 전용 가로채기 변경을 되돌린 뒤 합성 주소를 사용했던 앱의 캐시도 삭제해야 합니다. 주소 풀만 끄면 이전 합성 주소에 계속 연결을 시도하는 프로세스가 남을 수 있습니다. 복구한 뒤 일반 DNS로 기본 연결을 확인하고 FakeDNS를 다시 도입할지 결정하세요. 활성화 전 DNS와 라우팅 설정을 기록해 두면 구독 구성 전체를 다시 만들지 않고 이 두 계층만 복구할 수 있습니다.
다중 구독 관리 흐름
다중 구독 관리는 모든 서버를 하나의 큰 목록으로 합치는 것이 아니라 출처를 분리하고, 업데이트를 제어하며, 전환 결과를 확인하는 데 초점을 둡니다. 기본 구독, 예비 구독, 임시 테스트 구독은 각각 별도 그룹으로 만들어 항목의 출처를 추적할 수 있게 하세요. 구독이 늘어날수록 먼저 관리해야 할 것은 구성 간 관계입니다. 어느 그룹을 일상 연결에 쓰는지, 어느 그룹을 장애 시에만 사용하는지, 업데이트로 교체해도 되는 항목과 직접 보존해야 할 항목을 정리하세요.
출처별로 업데이트하고 용도에 따라 선택하기
먼저 출처별로 독립된 그룹을 만들고 용도와 업데이트 방식을 알아볼 수 있도록 메모를 작성하세요. 같은 구독 주소를 여러 용도 그룹에 복사해 분류를 대신하지 마세요. 업데이트 요청이 늘고 중복 항목이 생길 수 있습니다. 같은 출처를 서로 다른 방식으로 보아야 한다면 클라이언트의 필터 기능부터 확인하세요. 출처 그룹은 안정적으로 유지하고 검색이나 지원되는 필터로 용도를 찾는 편이 구독을 반복해서 가져오는 것보다 관리하기 쉽습니다.
예비 구독을 추가할 때는 먼저 해당 그룹만 업데이트하고 로그가 성공했는지, 목록 내용이 적절한지 확인한 뒤 실제 연결을 테스트하세요. 기본 서버를 곧바로 교체하거나 다른 출처까지 한꺼번에 업데이트하지 마세요. 구독에서 빈 결과가 반환되거나 새 구성이 시작되지 않더라도 영향 범위를 명확히 파악할 수 있습니다. 업데이트 실패와 빈 결과를 처리하는 방식은 클라이언트마다 다를 수 있습니다. 중요한 수동 설정은 별도로 백업하고 업데이트 때 유지될 것이라고 기대하지 마세요.
자동 업데이트 간격은 각 출처의 실제 변경 빈도에 맞춰야 하며, 자주 요청한다고 최신 상태가 유지되는 것은 아닙니다. 기기가 절전 중이거나 네트워크가 전환됐거나 프록시가 아직 시작되지 않은 상태에서는 자동 업데이트가 실패할 수 있습니다. 문제를 진단할 때는 자동 업데이트가 켜져 있는지만 보지 말고 마지막으로 성공한 로그를 확인하세요. 프록시를 통해 가져와야 하는 구독은 어떤 기존 연결에 의존하는지 확인해야 합니다. 기본 연결이 끊기면 예비 목록도 갱신할 수 없는 상황을 피할 수 있습니다.
중복 제거 및 활성 서버 관리
중복 여부는 별칭이 아니라 연결 매개변수로 비교해야 합니다. 주소와 포트가 같아도 사용자 식별자, 전송 경로, 서비스 이름, TLS 매개변수가 다를 수 있으므로 임의로 합치지 마세요. 클라이언트의 중복 제거 기능을 사용하기 전에 어떤 필드를 기준으로 삼는지 확인하고 복구 방법을 확보하세요. 이름만 비슷한 서버는 먼저 출처별로 보존하고 완전히 같은 항목임을 확인한 뒤 정리해야 유효한 예비 설정을 불필요하게 삭제하지 않습니다.
구독을 업데이트하면 항목 순서가 바뀌거나 내부 식별자가 교체될 수 있습니다. 목록 위치만 보고 서버를 선택하면 잘못 연결할 수 있으므로 연결 전에 별칭과 출처를 확인하세요. 실제 연결 속도 측정 결과도 업데이트 후 새 항목과 연결되지 않을 수 있으므로 이전 결과로 새 항목의 순서를 정하지 마세요. 기본 구독의 매개변수가 바뀌면 다시 테스트하고 해당 서버를 활성화한 뒤 구성을 다시 불러와 실제 앱 접속을 확인하세요.
예비 구독이 있다고 자동으로 장애 전환되는 것은 아닙니다. 일반적인 활성 서버 선택은 현재 아웃바운드 하나에 대응합니다. 해당 정책에 따라 전환하려면 상태 확인, 서버 선택, 부하 분산을 명시적으로 설정해야 합니다. 출처가 여러 개라고 자동으로 다른 서버가 연결을 이어받는다고 생각하지 마세요. 대부분의 일상 사용에서는 검증된 예비 경로 하나와 명확한 수동 전환 절차를 유지하는 편이 복잡한 자동화보다 복구하기 쉽습니다.
백업, 이전 및 민감 정보
백업에는 최소한 구독 그룹, 필요한 수동 서버, 사용자 지정 라우팅 항목, DNS 설정이 포함되어야 합니다. 클라이언트 내보내기에 어떤 항목이 들어가는지는 직접 확인하세요. 서버 링크만 내보내면 라우팅과 프로그램 설정이 포함되지 않을 수 있습니다. 백업 파일에는 구독 자격 증명과 서버 키가 들어 있을 수 있으므로 접근이 제한된 위치에 보관하세요. 다른 기기로 이전하기 전에 대상 클라이언트가 기존 프로토콜과 전송 방식을 지원하는지 확인해야 합니다. 파일 가져오기에 성공했다고 호환성 확인까지 끝난 것은 아닙니다.
데스크톱 v2rayN과 Android v2rayNG, v2flyNG의 전체 프로그램 설정을 서로 덮어쓰는 방식으로 이전하지 마세요. 서버 공유 형식은 교환할 수 있더라도 앱별 프록시, 시스템 프록시, TUN 가로채기, 로컬 디렉터리는 플랫폼마다 다릅니다. 이전할 때는 먼저 서버를 가져온 다음 대상 플랫폼에 맞게 트래픽 유입과 라우팅을 다시 설정하세요. Android의 백그라운드 정책도 새로 확인해 이전 기기의 안정성을 새 기기에 그대로 적용하지 않도록 합니다.
구독 주소가 작동하지 않으면 권한 만료, 주소 변경, 일시적인 네트워크 오류를 구분하세요. 권한 문제라면 기존 출처에서 유효한 주소를 받아 원래 그룹의 주소를 교체합니다. 네트워크 시간 초과라면 현재 연결과 업데이트 경로를 먼저 확인하세요. 만료된 주소를 자동 업데이트 대기열에 계속 남겨 두지 않는 것이 좋습니다. 주소를 교체한 뒤에는 이전 기록과 자격 증명이 포함된 화면 캡처를 정리해 오래된 링크가 동기화 메모, 클립보드 기록, 공개 문의에 남지 않도록 하세요.
네트워크를 전환한 뒤에는 클라이언트를 바로 재설치하지 말고 기본 서버부터 테스트한 다음 예비 출처를 확인하세요. 두 출처가 모두 같은 단계에서 실패한다면 로컬 포트, DNS, 트래픽 가로채기 문제일 수 있습니다. 한 출처만 실패한다면 해당 출처의 매개변수를 먼저 확인하세요. 시작 로그에 수신 대기 주소가 이미 사용 중이라고 표시되면 로컬 포트 충돌 확인 방법을 참고하세요. 관련 없는 문제를 해결하려고 구독을 전부 삭제하지 마세요.
사용자 지정 아웃바운드 및 설정 검증
아웃바운드는 코어가 연결을 다음 홉으로 보내는 방식을 정의하고, 라우팅은 태그를 통해 아웃바운드를 선택합니다. 직접 연결, 차단, 프록시는 서로 다른 출구 동작이지 구독 그룹의 종류가 아닙니다. 클라이언트는 보통 선택한 서버에 해당하는 프록시 아웃바운드와 보조 아웃바운드를 생성합니다. 화면에서 필요한 구성을 표현할 수 없을 때만 사용자 지정 설정을 고려하세요. 서버를 바꾸거나 도메인 예외를 추가하는 일상적인 작업에는 기존 서버 및 라우팅 화면을 우선 사용하세요.
태그 및 라우팅 참조
tag는 구성 내부에서 참조하는 식별자이므로 규칙의 outboundTag와 일치해야 합니다. 태그 이름 자체에는 특별한 기능이 없습니다. 이름을 direct로 적는다고 직접 연결이 되는 것이 아니라 프로토콜과 매개변수가 실제 동작을 결정합니다. 문제를 해결할 때는 태그가 존재하는지, 중복되지 않았는지, 프로토콜이 올바른지 함께 확인하세요. 이름이 다르면 규칙이 대상을 찾지 못할 수 있으며 클라이언트 로그에서 단서를 찾을 수 있습니다.
다음은 Xray를 사용한 완전한 로컬 SOCKS 직접 연결 테스트 구성입니다. 인바운드, 규칙, 아웃바운드의 관계를 이해하기 위한 예시이며 원격 프록시 연결은 제공하지 않습니다. 실행하기 전에 같은 수신 대기 포트를 사용하는 다른 인스턴스를 종료하고 로컬 전용으로 사용되는지 확인하세요. 모든 유입 요청은 직접 연결 아웃바운드로 명시적으로 전달됩니다. 따라서 원격 서버를 검증할 수 없으며 기존 구독을 대체하는 설정으로 오해해서도 안 됩니다.
{
"log": {
"loglevel": "warning"
},
"inbounds": [
{
"tag": "local-socks",
"listen": "127.0.0.1",
"port": 10808,
"protocol": "socks",
"settings": {
"auth": "noauth",
"udp": true
}
}
],
"outbounds": [
{
"tag": "direct",
"protocol": "freedom",
"settings": {}
},
{
"tag": "block",
"protocol": "blackhole",
"settings": {}
}
],
"routing": {
"domainStrategy": "AsIs",
"rules": [
{
"type": "field",
"inboundTag": ["local-socks"],
"outboundTag": "direct"
}
]
}
}예시에서 수신 대기 주소를 루프백 주소로 제한한 것은 인증되지 않은 로컬 프록시가 다른 기기에 공개되는 것을 막기 위해서입니다. 모든 인터페이스에서 수신하도록 바꾸면 접근 범위가 달라져 같은 네트워크의 기기가 해당 포트를 사용할 수 있습니다. LAN 공유가 꼭 필요하다면 접근 제어, 인증, 방화벽 규칙을 별도로 설계해야 합니다. 수신 대기 주소만 바꾸면 안 됩니다. 포트를 사용할 수 있는지도 로컬에서 실제 점유 상태를 확인해야 합니다.
클라이언트 생성 설정 및 사용자 지정 파일
GUI에서 관리하는 서버는 보통 클라이언트가 실행 설정을 생성합니다. 임시로 생성된 파일을 직접 편집하면 구성을 다시 불러오거나 서버를 바꿀 때 덮어써질 수 있습니다. 규칙을 계속 유지하려면 클라이언트가 지원하는 사용자 지정 설정 메뉴에 작성하세요. 완전한 사용자 지정 구성을 사용한다면 일반 서버 설정이 더 이상 관리하지 않는 기능이 무엇인지 파악해야 합니다. 생성된 결과와 GUI 필드를 동시에 수정한 뒤 두 설정이 계속 동기화될 것이라고 기대하지 마세요.
프록시 아웃바운드를 만들 때 주소, 포트, 사용자 자격 증명, 전송 방식, 보안 매개변수는 유효한 설정에서 가져와야 합니다. 추측으로 채워서는 안 됩니다. 프로토콜 이름이 같아도 전송 경로, 서비스 이름, 인증서 관련 매개변수는 다를 수 있습니다. 먼저 일반 서버 설정에서 연결을 검증한 다음 사용자 지정 구성으로 옮기는 것을 고려하세요. 이렇게 하면 연결 매개변수 문제와 다중 아웃바운드 참조 문제를 분리해 해결 범위를 줄일 수 있습니다.
아웃바운드가 여러 개 있다고 자동으로 연결이 연쇄되는 것은 아닙니다. 규칙에 따라 예비 아웃바운드를 선택하는 것은 조건별로 출구를 고르는 방식입니다. 하나의 프록시 아웃바운드가 다른 아웃바운드를 통해 연결되는 것은 체인 연결이며 특정 코어가 관련 기능과 필드를 지원해야 합니다. 아웃바운드 배열의 순서만 바꿔 두 동작을 서로 대신할 수는 없습니다. 체인 연결은 시작 의존성, 지연 시간, 장애 지점을 늘리므로 각 홉을 따로 검증한 뒤 순환 참조가 없는지 확인하세요.
기본 출구도 확인해야 합니다. 일부 구성에서는 어떤 규칙에도 일치하지 않을 때 첫 번째 아웃바운드를 사용하고, 다른 실행 구성 요소는 최종 출구를 별도 필드로 지정할 수 있습니다. 새 아웃바운드를 목록 앞에 넣기 전에 규칙에 일치하지 않은 트래픽이 어디로 가는지 확인하세요. 예시에서 인바운드 태그로 출구를 명시한 이유는 목록 순서만으로 추측하지 않도록 하기 위해서입니다. 실제로 옮길 때는 클라이언트 생성 규칙과 사용자 지정 규칙의 순서를 확인해 뒤쪽 규칙이 영원히 일치하지 않는 상황을 방지하세요.
단계별 테스트 및 복구 기준선
검증은 구성을 불러올 수 있는지 확인하고, 로컬 인바운드가 수신 대기하는지 살펴본 다음, 아웃바운드가 연결되는지 확인하고, 마지막으로 서비스 트래픽이 올바른 라우팅 규칙과 일치하는지 보는 순서로 진행합니다. 문법이 올바른 것은 첫 번째 단계의 일부 문제만 해결합니다. 알 수 없는 필드, 누락된 규칙 데이터, 존재하지 않는 태그는 시작 단계에서 오류를 일으킬 수 있습니다. 오류가 나타나면 원문과 관련 구성 위치를 먼저 보존하고, 포괄적인 안내 문구 하나만 보고 여러 매개변수를 동시에 바꾸지 마세요.
로컬 포트에는 연결되지만 서비스가 작동하지 않는다면 현재 아웃바운드가 실제로 선택됐는지 확인한 뒤 DNS, 원격 연결, 앱 프로토콜을 살펴보세요. 프록시를 통한 테스트에서는 테스트 도구가 올바른 로컬 프로토콜과 포트를 사용하도록 명시해야 합니다. HTTP 프록시 포트를 SOCKS 포트로 착각하지 마세요. 클라이언트 버전과 실행 모드에 따라 수신 대기 구성이 달라질 수 있으므로 예전 가이드의 포트 조합을 기준으로 추측하지 말고 상태 표시줄과 현재 설정을 확인하세요.
일시적으로 로그 상세도를 높이면 아웃바운드 선택을 판단하는 데 도움이 되지만, 로그에는 대상 도메인, 서버 주소, 사용 패턴이 포함될 수 있습니다. 문제를 찾은 뒤에는 평소 로그 수준으로 되돌리고 공유하기 전에 민감한 정보를 삭제하세요. 구성이 계속 불안정하다면 검증된 일반 서버, 기본 라우팅, 기본 DNS로 돌아가 연결을 복구한 뒤 사용자 지정 설정을 하나씩 추가하세요. 백업에는 최근 편집본뿐 아니라 실제로 시작되는 기준 설정을 보존해야 합니다.