이미 WireGuard 서비스와 설정을 보유하고 있으며 Shadowrocket에서 매개변수를 확인하려는 사용자에게 적합한 글입니다. 먼저 로컬 기기와 원격 기기의 신원을 구분한 뒤 Address, Endpoint, DNS, MTU를 살펴보고 연결, 규칙, 웹페이지 접속을 각각 확인합니다. 각 매개변수를 누가 제공하는지, 잘못 입력하면 어느 단계에 영향을 주는지 설명하며 바로 연결할 수 있는 서비스 설정은 제공하지 않습니다.
먼저 Interface와 Peer 구분하기
Shadowrocket의 WireGuard 매개변수는 사용자가 이미 보유한 서비스의 전체 설정에서 가져와야 합니다. 표준 WireGuard 텍스트에서 [Interface]는 로컬 인터페이스를, [Peer]는 원격 대상을 나타냅니다. 직접 입력할 때는 두 항목이 같은 WireGuard 설정에 속하는지 확인하세요. 다른 기기의 Private Key, 현재 기기의 Address, 다른 서버의 Public Key를 조합해서는 안 됩니다.
WireGuard는 UDP를 통해 터널 통신을 전달합니다. 서버 주소와 포트는 패킷의 목적지를 결정하고, 키는 통신 양쪽이 서로를 인증할 수 있는지 결정합니다. 따라서 ‘주소가 확인됨’, ‘포트가 올바름’, ‘인증 성공’은 각각 별도로 점검해야 합니다.
Private Key, Public Key, Preshared Key
[Interface]의 PrivateKey는 로컬 기기의 Private Key입니다. 이 키에서 로컬 Public Key를 도출할 수 있으며, 원격 측에는 이 로컬 Public Key를 등록해야 합니다. 로컬 Private Key는 로그인 비밀번호도, 원격 Public Key도 아닙니다. Private Key를 바꾼 뒤 원격 측의 해당 등록 정보가 갱신되지 않으면 기존 설정으로 정상 통신할 수 없습니다.
| 설정 항목 | 입력 의미 | 자주 하는 실수 |
|---|---|---|
Interface.PrivateKey | 로컬 기기가 보유한 Private Key입니다. | 서버의 Public Key를 입력하거나 복사할 때 공백이나 따옴표가 섞이는 경우 |
Peer.PublicKey | 원격 측의 Public Key입니다. | 로컬 Public Key를 입력해 원격 신원과 일치하지 않는 경우 |
Peer.PresharedKey | 양측이 추가로 합의한 공유 키입니다. | 한쪽에만 설정하거나 양쪽의 값이 서로 다른 경우 |
Public Key에는 상대방의 Public Key를 입력해야 합니다. 로컬 Private Key에서 계산한 Public Key가 아닙니다. 서비스 설정에 클라이언트 Public Key와 서버 Public Key가 모두 표시된다면 각 항목이 속한 섹션을 확인하세요. [Peer] 아래의 PublicKey가 여기서 확인해야 할 원격 신원입니다.
Preshared Key는 선택 항목이지만, ‘선택’이라고 해서 한쪽에서 임의로 삭제해도 되는 것은 아닙니다. 원본 설정에 항목이 있으면 그대로 유지하고, 없으면 직접 만들어 입력하지 마세요. +, /, =가 포함된 Base64 텍스트는 온전히 복사해야 합니다. URL 인코딩을 하거나 끝의 =를 불필요한 문장부호로 보고 지우지 마세요.
Address와 Endpoint는 서로 다른 단계입니다
Address는 터널 안에서 로컬 기기에 할당되는 주소이며, 보통 CIDR 접두사 길이를 포함합니다. 예를 들어 10.66.0.2/32는 IPv4 인터페이스 주소를 나타냅니다. 듀얼 스택 설정에는 fd00:66::2/128와 같은 IPv6 주소가 포함될 수도 있습니다. 이는 형식 예시일 뿐이며, 서비스에서 실제로 할당한 값을 대신하지 않습니다. Address는 원격 서버 주소도, 기기의 현재 Wi-Fi 로컬 네트워크 주소도 아닙니다.
- Address: 원본 설정에 따라 입력하고
/32,/128등의 접두사 길이를 유지하세요. 화면에서 IPv4와 IPv6가 별도 입력란으로 나뉘어 있다면 각각 해당하는 곳에 입력하고, 두 주소를 하나의 입력란에 억지로 합치지 마세요. - Endpoint: 원격에서 접속할 수 있는 도메인 또는 IP와 UDP 포트입니다. 문서용 주소
192.0.2.10:51820은 형식 예시일 뿐, 접속 주소가 아닙니다. - 포트 분리: 화면에서 Address와 Port가 별도로 표시되면 서버 주소 입력란에는 포트를 붙이지 말고 Port에 따로 입력하세요. 흔한 예시가
51820이라고 해서 원본 설정의 다른 포트를 이 값으로 바꾸지 마세요. - IPv6 Endpoint: 표준 텍스트에서 포트가 포함된 IPv6 주소는
[2001:db8::10]:51820처럼 대괄호를 사용합니다. 화면의 별도 주소 입력란에 옮길 때는 해당 입력란의 형식에 맞춰 입력하세요.
표준 설정에는 AllowedIPs도 포함될 수 있습니다. 이 항목은 WireGuard Peer와 연결된 주소 범위를 나타내며 WireGuard의 라우팅 및 출발지 주소 검사에 사용됩니다. Address와는 다르며 Shadowrocket의 전역 라우팅 규칙으로 간주할 수도 없습니다. 편집 화면에 대응하는 항목이 있는지는 실제로 표시되는 필드를 기준으로 확인하세요. 0.0.0.0/0이 있다고 해서 Shadowrocket의 모든 요청이 반드시 해당 항목을 거친다고 단정하지 마세요.
DNS와 MTU: 이름 해석과 패킷 크기를 따로 확인하기
DNS는 도메인 이름을 주소로 변환하며 키 오류를 해결하지 않습니다. 표준 WireGuard 파일의 DNS는 클라이언트 도구에서 사용하는 설정 규약이지, WireGuard 핸드셰이크의 인증 매개변수가 아닙니다. Shadowrocket에서는 현재 Config와 Settings에서 실제 적용 중인 DNS 설정도 함께 확인해야 합니다. 원본 파일에 DNS 주소가 있다고 해서 실행 중에도 반드시 그 주소를 사용한다고 볼 수는 없습니다.
| 매개변수 | 확인할 사항 | 관찰할 수 있는 현상 |
|---|---|---|
DNS | DNS 리졸버에 연결할 수 있는지, 터널을 통해서만 접근 가능한지, Endpoint 도메인을 먼저 확인할 수 있는지 살펴봅니다. | 도메인 이름 해석 오류가 발생하지만, 알려진 대상에 대한 연결 테스트에는 응답이 있을 수 있습니다. |
MTU | 먼저 원본 설정을 그대로 사용합니다. 터널로 캡슐화한 뒤 패킷 크기가 실제 네트워크 경로의 한도를 넘는지 확인합니다. | 작은 요청은 성공하지만 큰 응답이나 업로드가 멈추고, 일부 웹페이지가 오래 로드됩니다. |
PersistentKeepalive | 원본 설정에서 주기적인 Keepalive 패킷을 요구하는지, 현재 네트워크에서 NAT 매핑이 만료되는지 확인합니다. | 오래 유휴 상태였다가 처음 접속하면 실패하지만 다시 연결하면 잠시 정상으로 돌아옵니다. |
MTU의 단위는 바이트입니다. 1420은 흔히 참고하는 값이지 모든 네트워크에 최적인 고정값은 아닙니다. 원본 설정에 MTU가 지정되어 있다면 먼저 그 값으로 확인하세요. ‘큰 요청은 멈추지만 작은 요청은 정상’과 같은 현상이 반복될 때만 한 번에 이 항목 하나씩 바꿔 보세요. 예를 들어 1420에서 1380으로 낮춘 뒤 같은 페이지나 업로드를 다시 테스트하고 결과를 기록합니다. 개선되지 않으면 원래 값으로 되돌리고 DNS와 규칙을 동시에 바꾸지 마세요.
원본 설정의 PersistentKeepalive = 25는 Keepalive 간격이 25초라는 뜻이지, 시간 초과나 재시도 횟수를 의미하지 않습니다. Keepalive가 필요한지는 네트워크와 서비스 설정에 따라 다릅니다. 올바른 키, Endpoint 또는 사용 가능한 UDP 경로를 대신할 수는 없습니다.
Home에서 입력하고 단계별로 확인하기
Home에서는 연결 항목을 관리하고, Config에서는 규칙 설정을, Settings에서는 앱 설정을 관리합니다. WireGuard 매개변수 입력과 규칙 설정 가져오기는 별개의 작업입니다. 전자는 연결 방식을 제공하고 후자는 어떤 요청에 해당 연결을 사용할지 결정합니다. 화면에 따라 일부 필드가 펼쳐지는 방식은 달라질 수 있습니다. 표준 설정의 항목과 화면의 필드를 목록 순서대로 붙여 넣지 말고 의미에 맞춰 대응하세요.
-
원본 설정 준비하기
사용자가 이미 보유한 서비스에서 받은 원본 설정을 보관하고 Interface와 Peer가 같은 기기에 해당하는지 확인합니다. 테스트 후 되돌릴 수 있도록 먼저 기존 Global Routing 상태를 기록하세요.
-
유형 선택하기
Home → 오른쪽 상단 ‘+’ → Type → WireGuard로 이동합니다. 기존 항목을 수정하려면 Home에서 해당 항목의 편집 화면을 여세요. 내용이 비슷한 항목을 여러 개 만들 필요는 없습니다.
-
매개변수 연결하기
Endpoint를 서버 주소와 Port에, Interface.PrivateKey를 Private Key에, Peer.PublicKey를 Public Key에 대응시킵니다. Address, Preshared Key, MTU는 원본 설정과 편집 화면의 실제 항목을 하나씩 비교한 뒤 저장하세요.
-
규칙 영향 분리하기
Home으로 돌아가 저장한 WireGuard 항목을 선택하고, 테스트 중에는 Global Routing → Proxy를 사용합니다. 연결을 켠 뒤 접속 가능한 것으로 확인된 HTTPS 페이지를 테스트하세요. Config 규칙의 영향을 먼저 줄일 수 있지만 DNS와 기타 적용 중인 설정도 확인해야 합니다.
-
평소 설정 복원하기
기본 접속이 확인되면 원래 Global Routing 설정으로 되돌린 뒤 같은 대상을 다시 테스트합니다. Settings → On Demand가 켜져 있다면 문제를 확인하는 동안 자동 연결을 잠시 꺼 두어 수동으로 연결을 끊은 뒤 다시 연결되는 일을 방지하세요. 테스트가 끝나면 원래 상태로 복원합니다.
연결 스위치가 켜졌다는 것은 로컬 기기에서 연결 절차가 시작됐다는 뜻일 뿐, 원격 측의 WireGuard 핸드셰이크가 완료됐다는 증거는 아닙니다. 지연 테스트에 값이 표시되어도 웹페이지 접속 확인을 대신할 수 없습니다. 테스트 대상과 방식이 실제 요청 경로와 다를 수 있습니다. 도메인 해석 결과, 대상 접속 결과, 확인 가능한 연결 기록을 함께 살펴보세요.
Global Routing이 확인 결과에 미치는 영향
아래에서는 테스트 결과가 달라지는 이유를 설명하기 위해 Shadowrocket의 세 가지 라우팅 방식을 비교합니다. Global Routing에는 Scene도 표시될 수 있지만, 이 글에서는 이를 분리 테스트의 기준으로 삼지 않습니다. 권장 Config는 확인된 규칙을 일상적으로 사용한다는 뜻이며, 임의의 설정 파일이 모두 바로 적용된다는 의미는 아닙니다.
Config
권장현재 Config의 규칙과 정책에 따라 요청을 처리합니다. 먼저 일치하는 규칙이 결과를 결정하므로 WireGuard 항목을 사용할 수 있어도 모든 도메인이 이를 사용한다는 뜻은 아닙니다.
적합한 경우: 기본 연결 확인 후 일상적인 규칙 기반 라우팅
Proxy
프록시 방식으로 트래픽을 처리해 일반 라우팅 규칙의 영향을 일시적으로 줄일 수 있습니다. 테스트 전에 현재 선택된 연결이 확인하려는 WireGuard 항목인지 확인하세요.
적합한 경우: 매개변수 입력 후 짧게 분리 테스트할 때
Direct
대상에 직접 연결합니다. 이때 웹페이지가 열리더라도 WireGuard 매개변수가 올바르다는 뜻은 아닙니다. Proxy에서 같은 대상에 접속한 결과와 구분해 기록하세요.
적합한 경우: 현재 네트워크에서 직접 접속한 결과와 비교할 때
Config로 돌아간 뒤 일부 대상만 실패한다면 규칙 순서와 해당 정책에서 실제로 선택된 항목을 확인하세요. DOMAIN-SUFFIX는 도메인 접미사로, IP-CIDR은 IP 대역으로, GEOIP는 IP 지리 데이터베이스를 기준으로 매칭합니다. FINAL은 앞선 규칙에 일치하지 않은 요청에 최종 동작을 지정합니다. Config에서만 발생하는 규칙 매칭 문제를 해결하려고 Private Key를 반복해서 바꾸지 마세요.
자주 발생하는 입력 문제와 점검 순서
Private Key를 입력했는데도 연결되지 않는 이유는 무엇인가요?
Home에서 해당 항목의 편집 화면을 열고 Type, Endpoint 주소, Port, Private Key, 상대방의 Public Key를 차례로 확인하세요. 이어서 원격 측에 해당 Private Key에 대응하는 로컬 Public Key가 등록되어 있는지 확인합니다. Preshared Key가 제공되었다면 양쪽의 값도 일치해야 합니다. Private Key의 글자 수만 확인해서는 부족합니다.
Address에 서버 IP를 바로 입력해도 되나요?
그렇게 바꾸면 안 됩니다. Address는 서비스에서 할당한 터널 내 로컬 주소이고, 서버의 공인 주소는 Endpoint입니다. 원본 설정의 Interface.Address에 따라 복원하고 접두사 길이를 유지하세요. Address를 받지 못했다면 먼저 기존 서비스의 관리자에게 확인하세요.
Wi-Fi에서는 정상인데 셀룰러 네트워크에서는 연결되지 않으면 어떻게 하나요?
먼저 두 네트워크에서 같은 항목, 같은 Global Routing, 같은 테스트 대상을 사용해 테스트 조건이 달라지는 문제를 배제합니다. 이어서 Endpoint의 IPv4/IPv6 연결 가능 여부와 UDP 경로를 확인하세요. 유휴 상태 뒤에만 문제가 발생한다면 원본 설정의 PersistentKeepalive를 확인하고, 큰 요청에서만 실패한다면 MTU를 별도로 테스트하세요.
구독을 업데이트한 뒤 수동으로 수정한 값이 사라지는 이유는 무엇인가요?
구독으로 관리되는 항목은 업데이트할 때 매개변수가 다시 기록될 수 있습니다. 먼저 수정 중인 항목이 수동으로 만든 항목인지 구독으로 생성된 항목인지 확인하고, 덮어쓴 필드와 구독 소스에서 반환된 설정을 비교하세요. 장기적으로 수정할 때는 기존 서비스에서 제공한 원본 설정과 일치시켜야 합니다. 새로고침할 때마다 무작정 같은 내용을 다시 수정하지 마세요.
MTU를 낮추면 모든 로딩 문제가 해결되나요?
그렇지 않습니다. 먼저 Proxy에서 대상에 접속할 수 있는지 확인하고, DNS 이름 해석도 점검하세요. 반복해서 재현되는 큰 패킷 관련 증상이 있을 때만 MTU를 추가로 테스트할 근거가 됩니다. 키 불일치, 잘못된 포트, DNS 연결 불가 문제는 MTU를 낮춰도 자동으로 해결되지 않습니다.
문제 해결이 끝나면 사용한 네트워크, Global Routing, 테스트 대상, 변경 항목과 결과를 기록하세요. 기존 서비스의 관리자에게 문의할 때는 ‘같은 대상이 Proxy에서는 실패하고 Direct에서는 정상’ 또는 ‘작은 요청은 성공하지만 업로드가 멈춤’처럼 현상을 설명할 수 있습니다. 단, 키와 개인 설정은 가려야 합니다. 전체 설정을 공개하는 것보다 명확한 비교 기록이 문제 파악에 도움이 됩니다.