Shadowrocket WireGuard 설정 방법: Private Key, Public Key, 주소, DNS 및 MTU 입력법

1. 입력 전에 설정 출처와 항목 구분 확인하기

Shadowrocket의 WireGuard 유형으로 연결하려면 유효한 상대 Peer 설정이 필요합니다. 서버 주소만으로는 연결할 수 없습니다. 먼저 이용 중인 서비스와 설정이 있거나 WireGuard 상대 Peer를 직접 관리하고 있어야 합니다. 이 사이트는 서버나 구독을 제공·판매·추천하지 않습니다. 현재 보유한 정보가 일반 구독 링크뿐이라면 WireGuard 유형 항목이 실제로 포함되어 있는지 확인하세요. 구독 URL을 서버 주소에 입력하면 안 됩니다.

일반적인 WireGuard 설정은 [Interface]와 [Peer] 두 부분으로 나뉩니다. 전자는 로컬 장치의 신원과 터널 인터페이스를, 후자는 원격 장치의 신원과 연결 대상을 설명합니다. Shadowrocket에서는 이 정보가 서버 편집 화면의 항목에 대응됩니다. 항목 순서와 표시 이름은 현재 화면을 기준으로 확인하고, 아래에서는 설정 원본과 대조하기 쉽도록 원래 키 이름을 그대로 사용합니다.

설정을 받으면 먼저 안전한 사본을 보관한 뒤 입력하세요. 공개적으로 도움을 요청할 때 Private Key, Preshared Key 또는 전체 구독 링크를 올리지 마세요. 이러한 정보는 연결 권한과 직접 연결될 수 있습니다. 형식만 확인하려면 구체적인 키를 공개하지 않고 길이, 공백 포함 여부, 설정 파일의 어느 부분에 있는지만 설명하면 됩니다.

2. Private Key와 Public Key: 로컬 Private Key와 상대 Public Key는 서로 바꿔 쓸 수 없습니다

[Interface]의 PrivateKey는 클라이언트의 Private Key이며, 상대 측에 등록된 클라이언트 Public Key와 짝을 이뤄야 합니다. [Peer]의 PublicKey는 원격 서버의 Public Key로, 상대를 식별하는 데 사용됩니다. 둘 다 Base64 문자열처럼 보여도 용도가 다릅니다. 모양만으로 구분할 수 없으며, 클라이언트 자신의 Public Key를 상대 Peer의 Public Key 항목에 입력해서도 안 됩니다.

WireGuard 표준 키는 Base64로 인코딩하면 보통 44자이며 끝에 =가 보일 수 있습니다. 길이가 맞는 것은 형식이 올바를 가능성을 나타낼 뿐, 키가 서로 맞는다는 뜻은 아닙니다. 붙여넣기 전에 앞뒤 공백과 따옴표, 줄바꿈은 제거하되 키에 포함된 +, /, =는 그대로 유지하세요.

• 클라이언트 Private Key를 새로 만들었다면, 상대 측에도 해당 키에서 파생된 새 클라이언트 Public Key를 등록해야 합니다. 로컬 장치만 변경해서는 연결이 복구되지 않는 경우가 많습니다.
• 서버 측 [Interface]의 PrivateKey를 클라이언트에 복사하지 마세요. 해당 클라이언트 전용으로 발급된 설정이 필요합니다.
• 원본 설정에 PresharedKey가 없다면 입력하지 마세요. PrivateKey나 PublicKey를 대신 입력해서는 안 됩니다.
• 두 기기에서 동일한 클라이언트 신원을 동시에 사용하지 마세요. 상대 측이 최근 활동한 Endpoint로 응답을 보내면 두 기기의 연결이 번갈아 끊길 수 있습니다.

3. Address, Endpoint 및 포트: 터널 안팎의 주소 구분하기

Address는 터널 내부 주소이고, Endpoint는 원격 서버에 연결할 때 사용하는 외부 주소입니다. 서로 바꿔 쓸 수 없습니다. 예를 들어 클라이언트에 10.66.0.2/32를 할당하고 Endpoint를 192.0.2.10:51820으로 지정했다면, 앞의 값은 터널 안에서의 로컬 신원을, 뒤의 값은 암호화된 UDP 패킷을 보낼 위치를 나타냅니다. 여기 사용된 Endpoint는 문서 설명용 주소이므로 실제 연결에는 사용할 수 없습니다.

/32는 IPv4 Prefix 길이이며 포트가 아닙니다. IPv6 단일 주소 설정에는 /128이 쓰이기도 합니다. 화면에서 IPv4 주소를 별도로 입력하도록 되어 있다면 포트나 Endpoint 전체를 함께 붙여 넣지 마세요. IPv6 주소는 원본 설정에 명시되어 있고 네트워크 경로도 지원하는 경우에만 입력해야 합니다. 임의로 만들어 넣지 마세요.

WireGuard의 AllowedIPs는 Peer가 전달할 수 있는 대상 범위와 수신 경로 검증 범위를 지정합니다. 클라이언트 Address를 다르게 표현한 항목이 아닙니다. 원본 설정에 0.0.0.0/0과 ::/0이 있더라도 Shadowrocket에서 해당 서버를 사용할지는 Global Routing과 Config 규칙을 함께 확인해야 합니다. 이 두 항목만으로 모든 앱의 트래픽이 해당 서버를 사용한다고 단정할 수 없습니다.

4. Home에서 WireGuard를 추가하고 기본 연결 확인하기

처음 입력할 때는 서버 하나만 확인하고 라우팅, DNS, MTU를 동시에 변경하지 마세요. 그래야 문제가 생겼을 때 어떤 변경이 결과에 영향을 줬는지 파악할 수 있습니다. 아래 단계의 메뉴는 WireGuard 서버를 추가하는 곳이며, Config는 구성 파일과 규칙을 관리하는 곳입니다. 두 메뉴를 혼동하지 마세요.

1. 유형 선택

   Home → + → Type → WireGuard로 이동합니다. 편집 화면으로 돌아오면 유형이 WireGuard로 유지되어 있는지 확인한 뒤 입력을 계속하세요.

2. 연결 정보 입력

   Endpoint의 호스트와 포트를 각각 해당 항목에 입력합니다. 예를 들어 문서용 주소 192.0.2.10:51820은 주소와 포트로 나눠 입력해야 합니다. 실제 설정에는 유효한 사용자 정보를 사용하세요.

3. 키 확인

   클라이언트 Private Key와 상대 Peer의 Public Key를 입력하고, 원본 설정에 따라 로컬 터널 주소를 추가합니다. Preshared Key는 명시된 경우에만 입력하세요.

4. 저장 후 선택

   서버를 저장한 다음 Home으로 돌아가 해당 항목을 선택합니다. 처음 연결할 때 시스템에서 VPN 구성 추가를 요청하면 안내에 따라 허용하세요. 권한을 허용했다는 것은 시스템 VPN 구성을 만들 수 있다는 뜻이지, 원격 서버에 연결할 수 있다는 보장은 아닙니다.

5. 연결 확인

   Home → Global Routing에서 잠시 Proxy를 선택하고 연결을 시작한 뒤, 접근 권한이 있는 테스트 대상으로 접속합니다. 확인이 끝나면 Global Routing을 원래 설정으로 되돌리고 평소 트래픽 분기도 점검하세요.

Global Routing에서 Proxy를 선택하면 규칙 변수를 줄여 확인할 수 있지만, 서버 자체의 접근 권한이나 네트워크 제한을 우회할 수는 없습니다. Direct는 WireGuard가 트래픽을 전달하는지 확인하기에 적합하지 않습니다. Config에서는 테스트 대상에 해당 서버를 사용하는 정책이 실제로 적용되는지 확인해야 합니다. 시스템에 VPN 연결됨으로 표시되더라도 로컬 터널 상태를 나타낼 뿐, 원격 키 협상이나 실제 서비스 접속이 성공했다는 뜻은 아닙니다.

5. DNS와 MTU 입력법: 먼저 기존 설정을 유지하고 하나씩 조정하기

DNS는 도메인 이름을 어떻게 해석할지 결정하며, 키 오류를 해결하지는 않습니다. 일반적인 WireGuard 설정에서 DNS는 해당 설정을 사용하는 앱이 처리하는 경우가 많으며 프로토콜 핸드셰이크 항목은 아닙니다. WireGuard 설정을 Shadowrocket에 직접 입력할 때 원본 파일의 DNS가 현재 설정의 DNS로 자동 적용된다고 가정하지 마세요. Settings → DNS와 현재 Config의 DNS 설정도 확인하고, 실제 활성화된 설정을 기준으로 판단해야 합니다.

• Endpoint에 도메인을 사용한다면 연결을 시작하기 전에 해당 도메인을 해석할 수 있어야 합니다. 사용할 수 있는 유일한 DNS가 아직 연결되지 않은 터널 안에 있다면 이름 해석이 연결에 의존하는 상황이 생길 수 있으므로, 먼저 원본 설정의 DNS 구성을 확인하세요.
• IP 주소로는 특정 제한 대상에 접속되지만 도메인으로는 실패한다면 DNS를 우선 확인하세요. 다만 HTTPS로 IP에 직접 접속하면 인증서나 가상 호스트 설정 때문에 실패할 수 있으므로, 이 현상만으로 원인을 단정할 수는 없습니다.
• 내부 도메인을 서비스 제공자가 지정한 DNS로만 해석할 수 있다면 다른 네트워크의 DNS를 그대로 사용했을 때 터널은 연결되어도 내부 리소스에 접근하지 못할 수 있습니다.

MTU는 인터페이스가 허용하는 최대 패킷 크기입니다. WireGuard는 바깥쪽 캡슐화 데이터를 추가하므로 하위 경로에서 처리할 수 있는 크기가 터널 내부 패킷 크기를 제한합니다. MTU가 너무 크면 작은 요청은 되지만 큰 페이지 로딩이나 업로드가 멈출 수 있습니다. 너무 작으면 패킷 분할과 처리 부담이 늘어납니다. 패킷 손실이나 서버 부하도 같은 증상을 일으킬 수 있으므로 로딩이 느리다는 이유만으로 MTU 문제라고 단정하지 마세요.

테스트할 때마다 네트워크 유형, 기존 MTU, 변경한 값과 동일한 작업의 결과를 기록하세요. 낮춘 뒤에도 안정적으로 개선되지 않는다면 기존 값으로 되돌리고 UDP 연결 가능 여부, 패킷 손실, 서버 라우팅을 확인하세요. DNS 변경, 포트 변경, MTU 조정을 동시에 하면 접속이 복구되어도 원인을 파악할 수 없습니다.

6. 증상에 따라 점검하기: 키부터 라우팅까지 단계별 확인

문제 해결은 연결의 기본 조건부터 확인한 다음 실제 서비스 접속을 점검하세요. 포트 연결 가능 여부, 키 일치, 주소, 상대 측 전달 설정과 응답 경로가 정상이어야 DNS와 트래픽 분기를 확인할 의미가 있습니다. 서버를 직접 관리한다면 상대 측의 최근 핸드셰이크 시간과 송수신 카운터도 확인하세요. 기존 서비스 제공자가 관리한다면 민감한 정보를 가린 뒤 발생 시간과 증상만 전달하면 됩니다.

Proxy에서 테스트가 정상인데 Config로 되돌린 뒤 실패한다면 WireGuard 키를 새로 만들기보다 실제로 적용된 규칙과 정책을 확인하세요. 예를 들어 DOMAIN-SUFFIX,example.com,PROXY는 example.com과 그 하위 도메인에만 일치합니다. IP-CIDR은 IP 주소 대역을 기준으로, GEOIP는 IP 지리 데이터베이스를 기준으로 일치 항목을 찾습니다. FINAL은 앞선 규칙과 일치하지 않은 연결에 적용됩니다. 규칙은 위에서 아래로 처리되며 대상에 어떤 정책이 적용되는지는 현재 설정을 확인해야 합니다.