이 VPN 초보자 용어 정리는 실제 사용 순서에 맞춰 구성했습니다. 먼저 구독 링크를 받고, 클라이언트로 가져온 다음 노드를 선택하고 프로토콜을 확인합니다. 마지막으로 트래픽 분할, 전체 모드, 규칙 모드 중 필요한 방식을 결정합니다. 연결 문제의 원인은 회선 자체가 아니라 ‘구독’, ‘노드’, ‘프로토콜’, ‘실행 모드’를 같은 개념으로 보고 잘못된 부분을 수정한 경우도 많습니다.
이 개념을 이해하기 위해 복잡한 네트워크 이론을 먼저 공부할 필요는 없습니다. ‘설정은 어디에서 오는가’, ‘트래픽은 어디로 가는가’, ‘클라이언트는 트래픽을 어떻게 전달하는가’, ‘어떤 요청이 회선을 거쳐야 하는가’만 구분하면 대부분의 설정을 이해할 수 있습니다. 플랫폼마다 버튼 이름은 다를 수 있지만 기본 작동 단계는 대체로 같습니다.
구독에서 연결까지 전체 흐름 이해하기
정상적인 연결에는 서로 독립적인 여러 설정 단계가 포함됩니다. 구독은 클라이언트에 노드 정보를 제공하고, 노드는 선택 가능한 접속 대상을 설명합니다. 프로토콜은 클라이언트와 서버가 통신하는 방식을 정하며, 회선 유형은 접속 지점 이후 데이터가 어떤 네트워크 경로를 지나는지 보여줍니다. 트래픽 분할 규칙은 특정 요청을 노드로 처리할지 결정합니다.
| 용어 | 해결하는 문제 | 흔한 오해 | 문제 해결 시 먼저 확인할 항목 |
|---|---|---|---|
| 구독 | 사용 가능한 설정을 클라이언트에 전달하고 이후 업데이트를 지원합니다 | 구독 주소를 일반 웹페이지처럼 브라우저에서 열면 된다고 생각합니다 | 구독을 성공적으로 가져왔는지, 업데이트가 완료됐는지 확인합니다 |
| 노드 | 구체적인 접속 설정을 제공합니다 | 같은 지역의 노드는 반드시 같은 경로를 사용한다고 생각합니다 | 노드 이름, 지역, 프로토콜 및 연결 상태를 확인합니다 |
| 프로토콜 | 클라이언트와 서버가 데이터를 주고받는 방식을 정합니다 | 프로토콜 이름만 보고 실제 속도를 판단합니다 | 클라이언트가 해당 프로토콜과 전송 방식을 지원하는지 확인합니다 |
| 회선 유형 | 접속 후 데이터가 지나는 네트워크 경로를 설명합니다 | 회선 유형과 프로토콜을 같은 개념으로 봅니다 | 직접 연결, 중계 또는 IEPL 전용 회선 표시를 확인합니다 |
| 트래픽 분할 규칙 | 요청을 노드로 보낼지 직접 연결할지 판단합니다 | 클라이언트를 켜면 모든 트래픽이 자동으로 노드를 거친다고 생각합니다 | 규칙 일치 결과와 현재 실행 모드를 확인합니다 |
구독 링크란 무엇이며 클라이언트로 가져와야 하는 이유
구독 링크는 서비스 제공자가 생성해 클라이언트가 읽을 수 있도록 만든 설정 주소입니다. 노드 목록만 반환할 수도 있고, 그룹·규칙·DNS 설정이 포함된 전체 구성을 반환할 수도 있습니다. 브라우저에서 직접 열었을 때 텍스트나 다운로드 안내가 표시되거나 내용을 읽기 어려워도 링크가 손상된 것은 아닙니다. 구독 링크의 주 사용자는 웹브라우저가 아니라 호환 클라이언트이기 때문입니다.
가져오기 과정에서 클라이언트는 구독 내용을 요청하고 서버 주소, 포트, 프로토콜 매개변수, 노드 이름을 분석한 뒤 로컬 설정으로 저장합니다. 이후 ‘구독 업데이트’를 실행하면 클라이언트가 서버에서 제공하는 최신 버전을 다시 가져옵니다. 보통 새로 추가되거나 변경 또는 삭제된 노드가 동기화되지만, 로컬에서 직접 수정한 내용이 유지되는지는 클라이언트의 병합 방식에 따라 달라집니다.
- 서비스 페이지에서 구독 링크를 복사하고 일부만 잘라내지 마세요.
- 현재 플랫폼에 맞는 클라이언트를 열고 구독, 설정 또는 구성 파일 메뉴를 찾습니다.
- URL에서 가져오기를 선택한 뒤 전체 링크를 해당 입력란에 붙여 넣습니다.
- 저장한 다음 업데이트를 실행하고 클라이언트에 노드 또는 정책 그룹이 표시되는지 확인합니다.
- 노드를 선택한 뒤 시스템 프록시나 TUN 등의 트래픽 가로채기 방식을 켭니다.
- 실제로 이용하려는 웹사이트나 앱으로 트래픽 분할 결과를 확인합니다.
구독 링크에는 구독을 식별하기 위한 인증 정보가 포함되는 경우가 많으므로 비밀번호처럼 안전하게 보관해야 합니다. 링크를 공개 포럼에 올리거나 전체 주소가 보이는 스크린샷을 공유하거나 출처가 불분명한 온라인 변환 도구에 가져오면 다른 사람이 설정을 확인할 수 있습니다. 링크가 유출되었다고 의심되면 클라이언트에서 기존 설정만 삭제하지 말고 서비스 페이지에서 구독을 재설정하세요.
노드, 서버, 회선 유형은 서로 다른 개념입니다
클라이언트에서 말하는 ‘노드’는 선택 가능한 연결 매개변수의 묶음입니다. 일반적으로 표시 이름, 서버 주소, 연결 포트, 프로토콜 및 인증 정보가 포함됩니다. 노드 이름에 들어가는 지역·회선·용도 표시는 선택을 돕기 위한 설명이며, 노드 이름 자체가 네트워크 전송에 사용되는 것은 아닙니다.
‘서버’는 실제로 서비스를 제공하는 호스트나 접속 지점을 가리키는 의미가 강합니다. 반면 ‘노드’는 사용자가 클라이언트에서 보는 설정 단위입니다. 하나의 서버에 여러 프로토콜 설정을 구성할 수 있고, 같은 지역에도 전혀 다른 회선이 여러 개 존재할 수 있습니다. 따라서 두 노드에 같은 도시 이름이 표시된다는 이유만으로 접속 지점, 출구, 중간 경로가 같다고 볼 수는 없습니다.
직접 연결, 중계, IEPL 전용 회선은 무엇을 의미하나요
직접 연결은 클라이언트가 서비스 제공자가 설정한 별도의 중계 계층을 거치지 않고 대상 서버의 접속 지점에 직접 연결하는 방식입니다. 구조는 단순하지만 현지 통신사 라우팅, 네트워크 간 연동, 국제 출구의 변동에 더 직접적인 영향을 받습니다.
중계 회선은 먼저 가깝거나 접속하기 쉬운 지점에 연결한 뒤 중계 네트워크를 통해 출구로 전달합니다. 중계의 목적은 네트워크 경로를 조정하는 것이지 애플리케이션 계층의 프로토콜을 바꾸는 것이 아닙니다. 중계 지점이 안정적이면 일부 불리한 공용망 경로를 피할 수 있지만, 중계 구간 자체가 혼잡하면 추가 경로가 병목이 될 수도 있습니다.
IEPL 전용 회선은 일반적으로 전용 국제 이더넷 연결을 이용해 국경 간 구간을 전달하고, 접속 지점과 출구를 조합해 연결하는 방식을 뜻합니다. 이는 ‘어떤 프록시 프로토콜을 사용하는가’와는 별개의 문제입니다. VLESS 노드는 여러 회선에 구성할 수 있고, Trojan 노드도 직접 연결·중계·전용 회선을 이용할 수 있습니다. 프로토콜 이름만으로 회선 정보를 대신할 수는 없습니다.
Shadowsocks, VMess, Trojan, VLESS, Hysteria2, TUIC은 어떻게 봐야 하나요
프로토콜은 클라이언트와 서버가 세션을 설정하고 인증하며 데이터를 전송하는 방식을 정합니다. 프로토콜은 호환성, 전송 특성, TCP 또는 UDP 활용 방식, 클라이언트 설정에 영향을 주지만 최종 속도를 단독으로 결정하지는 않습니다. 실제 사용감은 회선 경로, 서버 부하, 로컬 네트워크, 혼잡 제어, 앱 트래픽 유형에도 영향을 받습니다.
| 프로토콜 | 핵심 특징 | 설정 시 주의할 점 | 일반적인 활용 판단 |
|---|---|---|---|
| Shadowsocks | 구조가 비교적 단순한 암호화 프록시 프로토콜이며 생태계가 성숙했습니다 | 암호화 방식, 비밀번호, 플러그인 매개변수가 서버와 일치해야 합니다 | 클라이언트에서 폭넓게 지원한다면 범용 연결 옵션으로 적합합니다 |
| VMess | V2Ray 생태계에서 흔히 사용되며 다양한 전송 계층과 함께 구성할 수 있습니다 | 인증 정보, 전송 방식, 시간 상태가 연결에 영향을 줄 수 있습니다 | 호환되는 설정이 이미 있다면 계속 사용할 수 있으며 이름만으로 성능을 판단해서는 안 됩니다 |
| Trojan | TLS와 함께 사용되는 경우가 많으며 표준 암호화 연결로 데이터를 전달합니다 | 도메인, 인증서 검증, 서버 이름이 정확히 일치해야 합니다 | 클라이언트가 TLS 매개변수를 충분히 지원하는 설정에 적합합니다 |
| VLESS | 인증 계층이 가벼우며 TCP, WebSocket, gRPC 등의 전송 방식과 조합할 수 있습니다 | VLESS는 여러 계층 중 하나일 뿐이며 TLS, REALITY, 전송 매개변수도 서로 맞아야 합니다 | 최신 Xray 생태계 설정을 사용하는 환경에 적합합니다 |
| Hysteria2 | QUIC과 UDP를 기반으로 하며 복잡한 네트워크에서의 전송 성능을 중시합니다 | 로컬 네트워크가 UDP를 제한하면 제대로 작동하지 않거나 연결에 실패할 수 있습니다 | 패킷 손실과 지터가 비교적 크지만 UDP를 사용할 수 있는 네트워크에 활용할 수 있습니다 |
| TUIC | 마찬가지로 QUIC과 UDP를 기반으로 하며 여러 데이터를 동시에 전달할 수 있습니다 | 클라이언트 버전, 인증 매개변수, 혼잡 제어 설정이 서로 호환되어야 합니다 | 서버에서 명확히 제공하고 현재 네트워크에서 UDP를 허용하는 경우에 적합합니다 |
WebSocket, gRPC, TCP, QUIC 같은 용어는 프로토콜과 함께 자주 등장하지만 서로 다른 계층에 속할 수 있습니다. 예를 들어 VLESS는 다양한 전송 방식 위에 구성할 수 있고, TLS 또는 REALITY는 연결 검증과 암호화 캡슐화를 담당합니다. 구독을 가져온 뒤에는 보통 이 매개변수들을 직접 다시 조합할 필요가 없습니다. 서버 설정과 맞지 않는 항목을 임의로 수정하면 연결에 실패할 수 있습니다.
‘프로토콜은 최신일수록 빠르다’는 말은 신뢰할 수 있는 기준이 아닙니다. Hysteria2와 TUIC은 UDP에 의존하므로 UDP를 허용하고 네트워크 지터가 큰 환경에서 더 적합할 수 있습니다. 반대로 UDP가 제한된 사무실 네트워크, 공용 네트워크 또는 특수한 접속 환경에서는 TCP 기반 설정이 연결을 더 쉽게 만들 수 있습니다. 사용 가능한 대체 프로토콜을 남겨 두고 현재 네트워크에서 직접 테스트하는 것이 올바른 방법입니다.
전체 모드, 규칙 모드, 직접 연결 모드 전환 방법
실행 모드는 ‘어떤 트래픽을 노드로 보낼지’를 결정합니다. 어떤 프로토콜로 노드를 사용하는지와는 관계가 없습니다. 같은 VLESS 노드를 규칙 모드에서도, 전체 모드에서도 사용할 수 있습니다. 모드를 바꿔도 노드의 회선은 자동으로 바뀌지 않고, 클라이언트가 요청을 처리하는 방식만 달라집니다.
규칙 모드: 일상적인 사용에 적합한 선택
규칙 모드는 도메인, IP, 앱, 포트 또는 규칙 모음을 기준으로 트래픽의 방향을 판단합니다. 일반적으로 국내 서비스는 직접 연결하고 국제 회선이 필요한 요청은 노드를 거치도록 설정합니다. 이렇게 하면 불필요한 우회를 줄이고, 출구 지역이 바뀌어 일부 국내 웹사이트에서 추가 인증이 발생하는 상황도 피할 수 있습니다.
규칙은 보통 정해진 순서대로 일치 여부를 확인하며 가장 먼저 일치한 규칙이 적용됩니다. 클라이언트의 ‘프록시’, ‘직접 연결’, ‘차단’은 서로 다른 처리 동작을 뜻하는 경우가 많습니다. 정책 그룹을 사용하면 여러 노드를 하나의 규칙 대상에 함께 지정할 수 있습니다. 특정 웹사이트가 잘못된 경로로 연결된다면 현재 선택한 노드만 확인하지 말고 연결 로그에서 일치한 규칙을 확인하세요.
DOMAIN-SUFFIX,example.com,PROXY
DOMAIN-SUFFIX,local.example,DIRECT
PROCESS-NAME,browser,PROXY
MATCH,DIRECT위 내용은 규칙 구조를 이해하기 위한 중립적인 예시입니다. 도메인 접미사에 프록시 또는 직접 연결을 지정할 수 있고, 앱 프로세스에도 별도의 정책을 지정할 수 있으며, 마지막의 MATCH는 앞에서 일치하지 않은 요청을 처리합니다. 클라이언트마다 필드 이름과 문법이 완전히 같지는 않으므로 한 형식을 모든 앱에 그대로 붙여 넣어서는 안 됩니다.
전체 모드: 규칙 문제인지 임시로 확인할 때 유용
전체 모드는 일반적으로 클라이언트가 이미 가로챈 트래픽을 현재 노드로 일괄 전달합니다. 짧은 시간 동안 문제를 진단할 때 유용합니다. 규칙 모드에서는 접속되지 않지만 전체 모드에서는 접속된다면 규칙 일치, DNS 결과, 정책 그룹 선택에 문제가 있을 가능성이 큽니다. 전체 모드에서도 실패한다면 노드, 프로토콜, 로컬 네트워크를 계속 확인해야 합니다.
‘전체’가 기기에서 발생하는 모든 트래픽을 반드시 뜻하는 것은 아닙니다. 시스템 프록시만 켠 경우 시스템 프록시를 따르지 않는 앱은 직접 연결할 수 있습니다. TUN이 가로채지 않은 트래픽, 독립적으로 구현된 네트워크 스택, 특수한 시스템 서비스도 클라이언트를 우회할 수 있습니다. 따라서 전체 모드는 클라이언트 내부의 판단 방식을 설명하는 말이지 기기 전체 트래픽을 절대적으로 포함한다는 뜻은 아닙니다.
직접 연결 모드: 로컬 네트워크 경로를 빠르게 복구
직접 연결 모드는 이미 가로챈 요청을 원격 노드로 보내지 않습니다. 특정 국내 웹사이트가 우회 연결 때문에 비정상적으로 작동하는지 확인할 때 유용하며, 국제 회선이 필요하지 않은 동안에도 사용할 수 있습니다. 트래픽 가로채기를 완전히 중지하려면 시스템 프록시나 TUN도 꺼야 합니다. 정책만 직접 연결로 바꿔도 클라이언트 프로세스 자체는 계속 실행되는 경우가 많습니다.
시스템 프록시, TUN, DNS 누수는 각각 무엇을 관리하나요
시스템 프록시는 운영체제에 프록시 주소를 등록해 해당 설정을 따르는 앱이 HTTP 또는 SOCKS 요청을 클라이언트로 전달하도록 합니다. 브라우저와 대부분의 일반 앱은 시스템 프록시를 읽을 수 있지만, 일부 게임·명령줄 프로그램·독립 런타임·자체적으로 네트워크 연결을 구현한 앱은 이를 무시할 수 있습니다.
TUN 모드는 가상 네트워크 인터페이스를 만들어 IP 계층에서 더 넓은 범위의 트래픽을 가로챈 뒤 클라이언트가 라우팅과 트래픽 분할을 처리하도록 합니다. 시스템 프록시를 지원하지 않는 앱에 더 적합하며 TCP, UDP, DNS 요청을 일관되게 처리하기도 쉽습니다. 다만 TUN에는 시스템 네트워크 권한이 필요한 경우가 많고, 다른 네트워크 필터링 도구·기업 보안 소프트웨어·기존 가상 네트워크 카드와 라우팅 충돌이 발생할 수 있습니다.
DNS는 도메인 이름을 IP 주소로 변환합니다. DNS 누수는 일반적으로 클라이언트의 규칙이나 암호화 회선으로 처리되어야 할 도메인 조회가 로컬 통신사 또는 예상하지 못한 다른 경로로 전송되는 현상을 뜻합니다. 이로 인해 조회 대상이 노출될 수 있고, 노드 출구 지역과 맞지 않는 결과를 받아 웹사이트가 다른 지역으로 연결되거나 부적절한 주소에 접속하거나, 페이지는 열리지만 콘텐츠를 이용하지 못할 수 있습니다.
DNS 문제를 처리할 때는 클라이언트 DNS 설정, 시스템 해석 설정, 브라우저의 암호화 DNS를 함께 확인해야 합니다. 브라우저가 별도의 해석 서비스를 지정하면 클라이언트의 기존 트래픽 분할 설계를 우회할 수 있습니다. 클라이언트가 Fake IP 또는 강화 모드를 사용한다면 관련 스니핑, 매핑, 제외 규칙도 확인해야 합니다. 노드에 연결된다고 해서 DNS 경로까지 올바르다는 뜻은 아니므로 모든 해석 문제를 노드 탓으로 단정하지 마세요.
Windows, macOS, Android, iOS 클라이언트의 차이 이해하기
각 플랫폼 클라이언트의 핵심 역할은 같지만 권한 구조는 다릅니다. Windows 클라이언트는 시스템 프록시, 가상 네트워크 카드, 서비스 모드를 함께 제공하는 경우가 많습니다. macOS 클라이언트는 시스템 네트워크 확장 또는 프록시 권한이 필요하고, Android는 보통 시스템 VPN 인터페이스를 통해 로컬 터널을 만듭니다. iOS와 iPadOS는 시스템이 허용하는 네트워크 확장 기능에 의존합니다. 화면에 모두 ‘연결됨’이라고 표시되어도 실제 가로채는 범위는 현재 모드에 따라 달라집니다.
데스크톱에서는 연결 로그, 규칙 일치, DNS 조회를 확인하기 쉬워 구독 분석과 라우팅 문제를 진단하기 좋습니다. 모바일 기기는 백그라운드 관리와 배터리 절약 정책의 영향을 받으므로 앱이 백그라운드로 전환되거나 무선 네트워크와 모바일 네트워크 사이에서 연결이 바뀌면 시스템이 터널을 다시 만들 수 있습니다. 이때 잠시 연결이 끊겼다고 해서 구독이 무효화된 것은 아닙니다. 먼저 클라이언트로 돌아가 시스템 터널 상태를 확인하세요.
같은 구독이라도 클라이언트마다 표시되는 내용이 다를 수 있으며, 이것이 반드시 설정 손실을 의미하지는 않습니다. 전체 설정을 지원하는 클라이언트는 정책 그룹·규칙·DNS 모듈을 보여줄 수 있지만, 노드 구독만 지원하는 클라이언트는 서버 항목만 추출할 수 있습니다. 일부 프로토콜이나 전송 방식에는 최신 코어 지원이 필요하므로 클라이언트가 노드 이름을 가져오더라도 해당 연결을 성공적으로 만들 수 있다는 보장은 없습니다.
클라이언트를 선택할 때는 구독 형식, 프로토콜 지원, 시스템 프록시 및 TUN 기능, 규칙 문법, 로그의 명확성을 우선 확인하세요. 화면이 비슷하다는 이유만으로 호환성을 판단하지 마세요. 서비스 페이지에서 명확히 제공하는 클라이언트와 설정 방식을 사용하면 매개변수를 일관되게 유지하기가 더 쉽습니다.
연결 문제는 여러 설정을 한꺼번에 바꾸지 말고 단계별로 확인하세요
효율적인 문제 해결에는 비교가 필요합니다. 한 번에 하나의 조건만 바꿔야 문제가 구독, 노드, 프로토콜, 회선, 모드, DNS 중 어디에 있는지 알 수 있습니다. 구독 업데이트, 프로토콜 전환, TUN 활성화, 규칙 교체, 시스템 DNS 변경을 동시에 하면 연결이 복구되어도 실제 원인을 알 수 없고, 다음에 같은 문제가 발생했을 때 다시 처음부터 시도해야 합니다.
- ✅ 먼저 구독이 업데이트되고 클라이언트에 전체 노드 이름이 표시되는지 확인합니다.
- ✅ 명확히 지원되는 노드를 선택하고 연결 로그에서 핸드셰이크가 완료됐는지 확인합니다.
- ✅ 같은 지역의 노드에 문제가 생기면 다른 회선 유형으로 바꿔 비교합니다.
- ✅ 규칙 모드에 문제가 있으면 잠시 전체 모드로 전환해 잘못된 규칙 일치인지 판단합니다.
- ✅ 브라우저는 되지만 다른 앱이 되지 않으면 시스템 프록시가 가로채는 범위를 확인하고 TUN이 필요한지 검토합니다.
- ✅ 페이지 지역이 맞지 않거나 도메인 해석에 문제가 있으면 클라이언트·시스템·브라우저의 DNS 경로를 확인합니다.
- ❌ 구독이 자동 생성한 인증, TLS, 전송 계층 또는 서버 이름을 임의로 수정하지 마세요.
- ❌ 출처가 불분명한 변환 페이지나 공개 콘텐츠에 구독 링크를 붙여 넣지 마세요.
로그에 구독 요청 실패가 표시되면 문제는 설정을 가져오는 단계에서 발생한 것입니다. 노드는 존재하지만 핸드셰이크에 실패한다면 프로토콜 호환성, 로컬 네트워크 제한, 노드 상태를 확인해야 합니다. 핸드셰이크는 성공했지만 특정 웹사이트를 이용할 수 없다면 규칙, DNS, 대상 웹사이트 자체의 제한을 계속 확인하세요. 연결 버튼을 반복해서 누르는 것보다 단계에 따라 판단하는 편이 효과적입니다.
용어를 실제 작업에 적용해 안정적인 사용 습관 만들기
초보자는 ‘클라이언트에 연결됨이라고 표시되면 모든 과정이 끝났다’고 생각하기 쉽습니다. 더 정확한 판단에는 몇 가지가 포함됩니다. 구독이 가져와지고 업데이트되는지, 선택한 노드가 현재 네트워크와 호환되는지, 시스템 프록시 또는 TUN이 대상 앱의 트래픽을 실제로 가로채는지, 트래픽 분할 규칙이 요청을 예상한 정책으로 보내는지, DNS 조회가 예상하지 못한 경로로 빠지지 않는지를 확인해야 합니다.
노드 이름은 빠르게 후보를 고르는 데 유용하지만 최종 선택은 용도에 따라야 합니다. 웹사이트 이용과 AI 도구 사용은 상호작용 안정성이 중요하고, 스트리밍은 출구 지역과 플랫폼 인식도 관련됩니다. 다운로드 작업은 지속적인 전송 성능과 트래픽 운영을 더 중시합니다. 특정 노드가 한 가지 상황에서 작동한다고 해서 모든 앱에 가장 적합하다고 판단하지 마세요.
프로토콜도 새 버전을 계속 수동으로 따라갈 필요는 없습니다. 구독에 작동하는 매개변수가 이미 포함되어 있다면 먼저 서비스 측에서 권장하는 설정을 사용하세요. 현재 네트워크에서 UDP 제한, TLS 검증 실패, 클라이언트 코어 비호환 같은 명확한 현상이 나타날 때만 프로토콜이나 전송 방식을 바꾸는 것이 좋습니다. 매개변수가 많을수록 근거 없는 수정은 줄여야 합니다.
규칙 모드는 장기간 유지하기 좋지만 규칙 자체는 업데이트해야 합니다. 웹사이트 도메인, 콘텐츠 전송 주소, 앱 인터페이스는 바뀔 수 있어 오래된 규칙이 새 도메인을 놓칠 수 있습니다. ‘홈페이지는 열리지만 로그인이나 이미지 로딩이 실패하는’ 경우에는 기기 전체를 장기간 전체 모드로 바꾸기보다 실패한 요청의 도메인이 잘못된 정책에 들어갔는지 확인하세요.