VPN 연결은 됐는데 작동하지 않는지 판단하는 가장 확실한 기준은 클라이언트의 초록색 아이콘이 아닙니다. 실제 트래픽이 기기에서 어디로 나가는지, 도메인을 어떤 DNS가 조회하는지, 대상 앱이 현재 라우팅을 따르는지를 확인해야 합니다. 연결 상태는 클라이언트가 특정 핸드셰이크를 완료했거나 로컬 프록시 포트를 열었다는 의미일 뿐, 브라우저·다운로드 도구·기타 앱이 모두 예상 경로를 사용한다는 증거는 아닙니다.
점검할 때는 노드, 프로토콜, DNS, 분할 라우팅 규칙을 동시에 바꾸지 마세요. 여러 변수가 함께 바뀌면 문제가 잠시 사라져도 어떤 설정이 영향을 줬는지 알기 어렵습니다. 먼저 직접 연결 상태를 기록한 뒤 노드에 연결하고, 외부 IP·DNS·대상 앱을 순서대로 확인하는 편이 안전합니다. 각 단계에서는 하나의 질문만 확인하세요.
연결됨과 트래픽이 실제로 전달되는 상태를 구분하세요
클라이언트마다 말하는 연결 성공의 의미는 완전히 같지 않습니다. 시스템 수준 터널을 사용하면 일반적으로 가상 네트워크 인터페이스를 만들고 운영체제에 라우팅을 추가합니다. 시스템 프록시를 사용하면 로컬에서 HTTP, SOCKS 또는 혼합 프록시 포트를 연 다음 시스템 프록시가 해당 포트를 가리키도록 할 수 있습니다. 일부 클라이언트는 로컬 코어만 실행하므로 앱 트래픽을 넘겨받는지는 브라우저 설정, 분할 라우팅 모드 또는 별도 구성에 달려 있습니다.
따라서 같은 기기에서도 브라우저는 프록시를 사용하지만 터미널 명령은 직접 연결될 수 있습니다. 대부분의 웹사이트는 노드를 거치면서도 로컬 네트워크, 특정 도메인 또는 지정 앱은 규칙에 따라 직접 연결될 수도 있습니다. 반드시 오류라는 뜻은 아니며, 클라이언트가 정해진 분할 라우팅 규칙을 실행한 결과일 수 있습니다. 핵심은 현재 결과가 사용자가 선택한 모드와 일치하는지입니다.
| 관찰된 현상 | 확인할 수 있는 내용 | 이것만으로는 증명할 수 없는 내용 | 다음 점검 항목 |
|---|---|---|---|
| 클라이언트에 연결됨으로 표시됨 | 핸드셰이크가 완료됐거나 로컬 프록시 코어가 실행됨 | 모든 앱이 노드를 사용함 | 연결 전후 외부 IP 비교 |
| 외부 IP가 변경됨 | 현재 테스트 요청이 다른 출구를 거침 | 다른 앱과 DNS 요청도 같은 경로를 사용함 | DNS와 분할 라우팅 규칙 확인 |
| DNS 리졸버가 변경됨 | 현재 도메인 조회가 다른 DNS 경로를 사용함 | 웹페이지 요청이 반드시 프록시를 거침 | 대상 앱을 하나씩 확인 |
| 특정 웹사이트에 정상적으로 접속됨 | 현재 해당 웹사이트의 요청 경로를 사용할 수 있음 | 기기 전체가 노드에 연결됨 | 다른 브라우저와 독립 앱 테스트 |
Shadowsocks, VMess, Trojan, VLESS, Hysteria2, TUIC 등의 프로토콜은 클라이언트와 원격 노드 사이의 데이터 전송을 담당합니다. 그러나 프로토콜 연결 성공과 시스템 트래픽이 프로토콜 코어로 들어가는지는 별개의 문제입니다. 어떤 프로토콜을 사용하든 최종적으로는 라우팅, 프록시 설정, DNS, 앱 동작을 기준으로 확인해야 합니다. 프로토콜만 계속 바꾸는 것으로는 시스템 프록시가 켜지지 않았거나 앱이 프록시를 우회하는 문제를 해결하기 어렵습니다.
1단계: 연결 전후 외부 IP 비교
외부 IP는 대상 사이트에 접속할 때 상대 서버가 확인하는 공인 주소입니다. 확인할 때는 먼저 노드를 끊고 신뢰할 수 있는 IP 조회 페이지를 열어 국가 또는 지역, 네트워크 운영자, 주소를 기록하세요. 그런 다음 대상 노드에 연결하고 같은 페이지를 새로 엽니다. 주소와 네트워크 소속이 바뀌고 선택한 노드의 대략적인 지역과 일치한다면, 해당 웹 요청은 프록시 출구를 통해 전송된 것입니다.
테스트 전에는 조회 페이지를 닫았다가 다시 열거나 브라우저의 시크릿 창을 사용해 이전 결과가 캐시되는 것을 피하는 것이 좋습니다. 브라우저에 별도 프록시 확장 프로그램이 설치돼 있다면 활성화 여부도 기록하세요. 확장 프로그램이 시스템 프록시를 덮어써 브라우저와 다른 앱의 결과가 달라질 수 있습니다. 테스트 중에는 시스템 클라이언트와 브라우저 확장 프로그램을 겹쳐 사용하지 말고 하나의 연결 방식만 유지하세요.
- 클라이언트 연결을 끊고 기존 IP 조회 페이지를 닫은 뒤 조회 페이지를 다시 열어 직접 연결 결과를 기록하세요.
- 확인할 노드에 연결하고 클라이언트가 연결됨 상태로 명확히 전환될 때까지 기다리세요.
- 조회 페이지를 다시 열고 기존 탭에 캐시된 문구만 확인하지 마세요.
- 주소, 지역, 네트워크 소속을 비교하고 지도에 표시된 위치만 보지 마세요.
- 다른 브라우저나 독립 앱으로 다시 확인해 결과가 일치하는지 살펴보세요.
지도상의 위치는 보조 정보로만 활용하세요. IP 데이터베이스는 등록 정보, 데이터센터 위치 또는 과거 기록을 바탕으로 위치를 추정하므로 데이터베이스마다 표시가 다를 수 있습니다. 출구가 바뀌었는지는 지도 핀보다 주소 변경과 네트워크 소속이 더 중요한 기준입니다. 선택한 노드가 일본에 있고 조회 결과도 해당 노드가 사용하는 일본 데이터센터 네트워크로 표시된다면 테스트 방향은 대체로 맞습니다. 연결 해제 전과 주소가 완전히 같다면 프록시가 트래픽을 넘겨받는 방식을 계속 점검해야 합니다.
외부 IP가 바뀌지 않을 때 확인할 항목
- ✅ 클라이언트가 로컬 포트만 실행한 것이 아니라 시스템 프록시 또는 가상 네트워크 인터페이스 모드를 활성화했는지 확인하세요.
- ✅ 브라우저가 직접 연결로 설정돼 있거나 다른 프록시 확장 프로그램이 시스템 설정을 덮어쓰고 있지 않은지 확인하세요.
- ✅ 현재 분할 라우팅 모드에서 IP 조회 사이트가 직접 연결 규칙에 포함되지 않았는지 확인하세요.
- ✅ 다른 네트워크 프록시 도구를 종료해 여러 클라이언트가 시스템 프록시와 기본 라우팅을 동시에 변경하지 않도록 하세요.
- ❌ 이전 페이지를 새로 고치는 것만으로 판단하지 마세요. 캐시된 콘텐츠는 전체 요청을 다시 보내지 않을 수 있습니다.
- ❌ 여러 프로토콜과 노드를 연속으로 바꾸지 마세요. 실제 트래픽 인계 문제를 가릴 수 있습니다.
특정 브라우저에서만 외부 IP가 바뀌지 않는다면 해당 브라우저에 독립 프록시 정책이 설정돼 있는지 확인하세요. 일부 브라우저는 시스템 프록시를 따르지만 일부 명령줄 도구는 기본적으로 시스템 프록시를 읽지 않습니다. 다운로드 도구와 게임도 직접 네트워크 연결을 만들 수 있습니다. 시스템 프록시 모드는 모든 앱의 자동 연결을 보장하지 않습니다. 기기 전체의 트래픽을 넘겨받으려면 클라이언트가 지원하는 가상 네트워크 인터페이스 또는 시스템 터널 모드를 사용하고 라우팅이 정상적으로 추가됐는지 확인해야 합니다.
2단계: DNS 요청 경로 확인
DNS는 도메인을 접속 가능한 주소로 변환합니다. 웹페이지 콘텐츠가 프록시를 거쳐도 도메인 조회까지 같은 경로를 사용한다고 단정할 수는 없습니다. 시스템이 여전히 로컬 네트워크가 지정한 DNS 리졸버로 조회를 보내면 접속 측에서 프록시 출구 지역과 다른 결과를 받을 수 있습니다. 지역 기반으로 동작하는 스트리밍 서비스, 다운로드 미러, 콘텐츠 전송 네트워크에서는 페이지는 열리지만 콘텐츠 오류가 발생하거나 노드 선택이 비정상적이고 로딩 속도가 불안정해지는 식으로 나타날 수 있습니다.
DNS 유출은 일반적으로 현재 개인정보 보호 또는 라우팅 목표에 따라 터널이나 지정된 암호화 DNS로 보내야 할 조회가 로컬 네트워크 인터페이스를 통해 다른 리졸버로 전달되는 현상을 말합니다. 로컬 리졸버가 확인됐다고 해서 모든 웹 콘텐츠가 직접 연결된다는 뜻은 아니지만, DNS 경로가 예상대로 통일되지 않았다는 의미이므로 클라이언트의 DNS 인계 옵션을 추가로 확인해야 합니다.
확인 방법은 외부 IP 점검과 비슷합니다. 먼저 연결 해제 상태에서 리졸버의 네트워크 소속을 기록한 다음 노드에 연결해 다시 테스트하세요. DNS 요청을 어느 네트워크가 처리하는지, 지역이 목표 출구와 뚜렷하게 충돌하지 않는지, 반복 테스트에서도 로컬 네트워크가 제공하는 리졸버가 섞이지 않는지를 중점적으로 확인합니다. 조회된 웹사이트 주소만 보지 마세요. 대형 웹사이트는 지역, 캐시, 부하에 따라 서로 다른 결과를 반환할 수 있습니다.
nslookup example.com
# 시스템의 현재 DNS 설정 확인
# Windows
ipconfig /all
# macOS
scutil --dns
# 일반적인 Linux 환경
resolvectl status이 명령어들은 서로 다른 내용을 확인합니다. nslookup은 현재 사용한 DNS 서버와 반환 결과를 보여줍니다. 시스템 네트워크 명령은 운영체제에 어떤 DNS가 설정돼 있는지 확인합니다. 하지만 어느 명령도 브라우저가 같은 리졸버를 사용한다고 단독으로 증명하지는 못합니다. 최신 브라우저는 보안 DNS를 활성화해 HTTPS로 조회를 별도 전송하면서 운영체제 설정을 우회할 수 있습니다. 브라우저와 시스템 결과가 다를 때는 브라우저의 보안 DNS 옵션을 확인하세요.
DNS 결과가 비정상일 때 흔한 원인
클라이언트가 TCP 또는 UDP 앱 트래픽만 프록시하고 시스템 DNS는 넘겨받지 않을 수 있습니다. 가상 네트워크 인터페이스 모드가 생성됐어도 DNS 라우팅은 기존 네트워크 인터페이스를 가리킬 수 있습니다. 브라우저가 자체 암호화 DNS를 사용할 수도 있습니다. 또한 분할 라우팅 규칙에 따라 한국 국내 도메인은 직접 조회하고 그 밖의 도메인은 원격 DNS로 보낼 수 있습니다. 마지막 방식은 흔한 분할 라우팅 설계이므로 리졸버가 다르다는 이유만으로 오류로 판단하지 말고 대상 도메인의 매칭 규칙과 함께 확인해야 합니다.
DNS를 변경한 뒤에도 결과가 그대로라면 시스템, 브라우저 또는 로컬 프록시 코어에 캐시가 남아 있을 수 있습니다. 먼저 브라우저를 다시 시작한 뒤 클라이언트 연결을 끊었다가 다시 연결하세요. 그래도 갱신되지 않으면 운영체제가 제공하는 DNS 캐시 삭제 기능을 사용할 수 있습니다. 캐시 삭제를 장기적인 해결책으로 여기지는 마세요. 연결할 때마다 수동 처리가 필요하다면 클라이언트의 DNS 인계와 라우팅 설정으로 돌아가 근본 원인을 확인해야 합니다.
3단계: 브라우저와 앱별로 하나씩 확인
브라우저의 외부 IP와 DNS를 확인했다고 해서 모든 소프트웨어가 정상 작동한다고 바로 추론할 수는 없습니다. 앱이 노드를 사용하는지는 시스템 프록시를 따르는지, 가상 네트워크 인터페이스가 인계하는지, 어떤 전송 프로토콜을 사용하는지, 분할 라우팅 규칙이 대상 주소와 어떻게 매칭되는지에 달려 있습니다. 브라우저, 터미널, 게임 플랫폼, 동영상 앱, 다운로드 도구에서 결과가 서로 다를 수 있습니다.
간단한 점검 기록을 만들어 앱 이름, 예상 경로, 실제 출구, DNS 결과, 접속 상태를 적어두는 것이 좋습니다. 가장 중요한 앱부터 테스트하고 특정 웹페이지가 열린다는 사실로 기기 전체를 판단하지 마세요. 한 앱만 비정상이고 다른 앱은 정상이라면 대개 노드 전체가 아니라 해당 앱의 프록시 설정, 프로토콜 지원 또는 분할 라우팅 규칙이 원인입니다.
| 앱 유형 | 일반적인 트래픽 인계 방식 | 차이가 발생하는 원인 | 중점 확인 항목 |
|---|---|---|---|
| 브라우저 | 시스템 프록시, 확장 프로그램 또는 보안 DNS | 확장 프로그램이 시스템 설정을 덮어쓰거나 DNS를 별도로 조회함 | 외부 IP, 브라우저 DNS, 확장 프로그램 상태 |
| 명령줄 도구 | 환경 변수, 명시적 프록시 또는 가상 네트워크 인터페이스 | 기본적으로 시스템 프록시를 읽지 않음 | 터미널과 브라우저에서 같은 요청의 출구가 다른지 확인 |
| 스트리밍 클라이언트 | 가상 네트워크 인터페이스 또는 시스템 라우팅 | 지역 확인이 외부 IP와 DNS를 함께 참조함 | 대상 도메인 규칙과 DNS 지역의 일치 여부 |
| 게임 및 실시간 통신 | 가상 네트워크 인터페이스, 프로세스 프록시 또는 라우팅 규칙 | UDP를 사용할 수 있어 시스템 프록시가 인계하지 못할 수 있음 | 프로세스가 규칙과 매칭되는지, UDP가 노드를 통과하는지 |
| 다운로드 도구 | 내장 프록시 또는 시스템 터널 | 자체적으로 도메인을 조회하거나 주소에 직접 연결할 수 있음 | 도구 내부의 프록시 설정과 실제 연결 경로 |
시스템 프록시는 주로 프록시 설정을 읽는 앱을 대상으로 합니다. 가상 네트워크 인터페이스 모드는 네트워크 계층에서 더 넓은 범위의 트래픽을 인계하므로 프록시 설정을 지원하지 않는 프로그램에 더 적합한 경우가 많습니다. 다만 라우팅 우선순위, 제외 규칙, 클라이언트 구현의 영향을 받습니다. Windows, macOS, Android, iOS, Linux는 네트워크 스택과 권한 모델이 다르므로 같은 구독을 서로 다른 클라이언트에 가져오면 시스템 프록시, 가상 네트워크 인터페이스, 앱별 분할 라우팅, DNS 인계 기능이 달라질 수 있습니다.
구독 링크는 클라이언트에 노드와 관련 설정을 제공하는 역할만 합니다. 가져오기에 성공했다는 것은 클라이언트가 설정을 받았다는 뜻이지 운영체제가 터널 생성을 허용했다는 뜻은 아니며, 분할 라우팅 규칙이 현재 플랫폼에 적용된다는 의미도 아닙니다. 처음 가져온 뒤 노드를 선택했는지, 올바른 모드를 활성화했는지, 시스템에 표시된 네트워크 설정 권한 요청을 처리했는지 확인하세요. 구독이 업데이트됐는데도 클라이언트가 이전 노드를 사용한다면 클라이언트에서 구독을 새로 고친 뒤 노드를 다시 선택하세요.
글로벌·규칙·직접 연결 모드가 결과에 미치는 영향
글로벌 모드는 더 많은 대상 트래픽을 프록시로 보내는 경우가 많지만, 로컬 네트워크, 클라이언트 자체 통신, 필요한 시스템 서비스는 제외될 수 있습니다. 규칙 모드는 도메인, 주소, 지역 또는 프로세스에 따라 프록시와 직접 연결을 결정하므로 부분적으로만 적용되는 것처럼 보이기 쉽습니다. 직접 연결 모드는 노드 설정을 유지하되 일반 트래픽은 전달하지 않아 프록시를 임시로 중지할 때 사용합니다. 이 모드를 잘못 선택하면 클라이언트는 계속 실행돼도 외부 IP는 바뀌지 않습니다.
규칙에는 적용 순서도 있습니다. 어떤 도메인이 먼저 직접 연결 규칙과 일치하면 뒤의 프록시 규칙은 해당 도메인을 다시 처리하지 않습니다. DNS 조회 후 주소에 직접 연결하는 앱은 도메인 기준으로만 작성된 규칙을 우회할 수도 있습니다. 점검할 때는 잠시 적용 범위가 더 넓은 모드로 전환해 비교해 보세요. 이후 앱이 정상화된다면 노드 자체는 사용할 수 있을 가능성이 높고, 원래 분할 라우팅 규칙의 매칭 문제를 중점적으로 확인해야 합니다. 비교가 끝나면 규칙 모드로 되돌리고 매칭 항목을 수정하세요.
연결된 것처럼 보이지만 프록시를 사용하지 않는 대표 원인
클라이언트가 로컬 프록시 포트만 실행함
일부 데스크톱 클라이언트는 코어를 독립적으로 실행할 수 있습니다. 이 경우 노드 연결은 성립하고 기기에도 사용 가능한 프록시 포트가 있지만 시스템 프록시가 켜지지 않아 일반 브라우저와 앱은 계속 직접 연결됩니다. 노드를 바꾸기보다 시스템 프록시를 활성화하거나 앱에 로컬 프록시 주소를 입력하거나 가상 네트워크 인터페이스 모드로 전환하세요.
여러 네트워크 도구가 동시에 라우팅을 변경함
두 클라이언트가 동시에 실행되면 나중에 시작한 소프트웨어가 시스템 프록시를 덮어쓸 수 있고, 가상 네트워크 인터페이스의 라우팅 우선순위가 충돌할 수도 있습니다. 겉으로는 양쪽 모두 정상적으로 연결된 것처럼 보여도 실제 트래픽은 다른 경로로 들어갈 수 있습니다. 점검할 때는 다른 프록시, 필터, 네트워크 디버깅 도구를 종료하고 현재 클라이언트만 남긴 뒤 외부 IP를 다시 비교하세요.
브라우저 캐시와 기존 연결이 새로 만들어지지 않음
노드를 바꾼 뒤에도 이미 열려 있는 페이지가 기존 연결을 재사용할 수 있고 DNS 결과가 캐시에 남아 있을 수 있습니다. 그 결과 새로 연 조회 페이지에는 새 출구가 표시되지만 기존 탭은 이전 상태를 유지합니다. 새로 고침을 반복하는 것보다 해당 탭이나 브라우저를 닫고 다시 테스트하는 편이 확실합니다. 연결을 오래 유지하는 데스크톱 앱도 완전히 종료한 뒤 다시 실행하세요.
IPv4와 IPv6 경로가 서로 다름
네트워크가 IPv4와 IPv6를 모두 제공하지만 클라이언트가 한 경로만 인계할 수 있습니다. 대상 사이트가 인계되지 않은 주소 체계를 우선 선택하면 외부 IP가 예상과 달라질 수 있습니다. 점검할 때는 조회 페이지가 각각 어떤 주소 유형을 보고하는지 확인하고, 클라이언트가 현재 시스템에서 활성화된 주소 체계를 지원하고 인계하는지 살펴보세요. 장기적인 해결책으로 특정 주소 체계를 단순히 끄기보다는 클라이언트와 라우팅 설정을 먼저 수정하는 것이 좋습니다.
규칙이 대상 도메인을 직접 연결로 보냄
규칙 모드에서는 광고 필터, 로컬 네트워크 보존, 지역별 라우팅, 사용자 지정 규칙이 결과에 영향을 줄 수 있습니다. IP 조회 사이트 자체가 직접 연결 목록에 포함돼 테스트 페이지에는 원래 출구가 표시되고 다른 대상은 이미 프록시를 거칠 수도 있습니다. 다른 조회 방법으로 교차 확인하고 클라이언트 연결 로그에서 규칙 매칭 정보를 살펴보세요. 로그는 도메인 매칭과 아웃바운드 선택을 확인하는 데 사용하며, 핸드셰이크 성공 한 줄만 봐서는 안 됩니다.
시스템 시간 또는 인증서 검증 오류
Trojan, VLESS와 TLS를 조합한 설정은 올바른 인증서 검증에 의존하며, TLS 또는 QUIC 기반 전송도 시스템 시간의 영향을 받을 수 있습니다. 시간 오차로 핸드셰이크가 실패하면 클라이언트 로그에 인증서, 시간 초과 또는 핸드셰이크 오류가 표시되는 경우가 많고 안정적으로 전송 가능한 상태에 들어가지는 않습니다. 먼저 시스템 자동 시간 동기화를 복구한 다음 서버 이름, 전송 매개변수, 구독 설정이 완전한지 확인하세요.
반복 실행할 수 있는 최종 점검 목록
개별 점검을 마친 뒤 정해진 순서로 한 번 더 확인하세요. 누락을 줄일 수 있고 네트워크, 클라이언트, 노드를 바꾼 뒤에도 같은 절차를 반복할 수 있습니다. 연결됨 화면 한 장만 저장하는 것보다 각 단계의 실제 결과를 기록하는 편이 진단에 훨씬 유용합니다.
- ✅ 노드 연결을 끊고 기준 외부 IP, 네트워크 소속, DNS 경로를 기록하세요.
- ✅ 대상 노드에 연결한 뒤 클라이언트 모드가 시스템 프록시, 가상 네트워크 인터페이스, 로컬 포트 중 무엇인지 확인하세요.
- ✅ 조회 페이지를 다시 열고 테스트 요청의 외부 IP가 예상대로 변경됐는지 확인하세요.
- ✅ DNS 경로를 확인하고 브라우저의 보안 DNS와 시스템 설정을 비교하세요.
- ✅ 브라우저, 터미널, 대상 앱을 각각 테스트하고 하나의 웹페이지로 전체 트래픽을 판단하지 마세요.
- ✅ 분할 라우팅 규칙의 매칭 결과를 확인해 문제가 있는 대상이 실수로 직접 연결에 배정되지 않았는지 살펴보세요.
- ✅ IPv4와 IPv6가 같은 트래픽 인계 정책으로 처리되는지 확인하세요.
- ✅ 한 번에 하나의 변수만 바꾼 뒤 다시 테스트하고 변경 전후의 차이를 기록하세요.
- ❌ 클라이언트 아이콘, 노드 이름, 구독 가져오기 성공을 최종 증거로 보지 마세요.
- ❌ 원인이 확인되기 전에 노드, 프로토콜, DNS, 클라이언트를 동시에 바꾸지 마세요.
외부 IP가 바뀌고 DNS 경로도 예상과 일치하지만 특정 앱만 사용할 수 없다면 해당 앱으로 범위를 좁혀 점검하세요. 시스템 프록시를 지원하는지, UDP를 사용하는지, 별도 프록시 설정이 있는지, 분할 라우팅 규칙과 매칭되는지를 확인하면 됩니다. 모든 앱의 외부 IP가 바뀌지 않는다면 클라이언트의 트래픽 인계 방식, 시스템 권한, 라우팅 추가 상태를 다시 확인하세요. 외부 IP가 계속 바뀌거나 연결이 자주 끊기면 클라이언트 로그에서 시간 초과, 핸드셰이크, 네트워크 전환 기록을 살펴보세요.
IEPL 전용 회선, 중계 노드, 공용망 직접 연결은 노드 간 또는 사용자와 출구 사이의 전송 경로를 설명하는 용어이며, 위의 확인 원칙을 바꾸지는 않습니다. IEPL은 일반적으로 전용 국제 전송 구간을 강조하고, 중계 노드는 먼저 중계 입구로 이동한 뒤 출구로 전달하며, 공용망 직접 연결은 원격 노드에 바로 연결합니다. 경로 구조와 관계없이 대상이 최종적으로 확인하는 주소는 출구 노드의 주소입니다. 기기에서 트래픽이 해당 경로로 들어갔는지는 여전히 외부 IP, DNS, 앱 테스트로 확인해야 합니다.