Shadowrocket 프로토콜 기술 가이드

프로토콜을 선택하기 전에: 프로토콜·전송·라우팅 계층

Shadowrocket에서 프로토콜을 선택한다는 것은 속도 등급을 붙이는 것이 아니라 서버와 동일한 통신 규약을 선택하는 것입니다. 서버가 특정 프로토콜만 지원한다면 클라이언트에서도 해당 유형을 사용해야 합니다. Add Server에서 유형만 다른 항목으로 바꿔도 서버의 기능이 달라지지는 않습니다. 구독을 가져온 항목에는 보통 필요한 설정이 이미 포함되어 있습니다. 수동으로 편집하기 전에 원래 항목을 보존해 두면, 확인할 문제를 여러 설정이 동시에 바뀌는 상황으로 만들지 않을 수 있습니다.

하나의 연결은 여러 역할로 구성됩니다

연결 정보를 네 계층으로 나누어 살펴볼 수 있습니다. 주소와 포트는 접속 지점을 정하고, 프로토콜과 인증은 상대방이 연결을 식별하는 방식을 정합니다. 전송과 암호화는 데이터가 전달되는 방식을, 라우팅 규칙은 어떤 요청을 해당 항목으로 보낼지를 결정합니다. 각 계층은 서로 관련되어 있지만 서로를 대신하지는 않습니다. 비밀번호가 맞아도 인증서가 올바르다는 뜻은 아니며, 인증서가 유효해도 서버가 해당 계정을 허용한다는 뜻은 아닙니다. 규칙이 PROXY를 지정해도 선택한 서버가 반드시 작동하는 것은 아닙니다. 계층별로 확인하면 “연결됨”으로 표시되는데도 웹페이지가 열리지 않는 이유가 여러 가지일 수 있음을 알 수 있습니다.

프로토콜 이름만으로 외부 전송 방식까지 모두 알 수 있는 것은 아닙니다. VMess와 VLESS는 여러 전송 설정과 조합할 수 있고, Trojan은 TLS 연결에서 흔히 사용됩니다. Hysteria2는 QUIC 기반 전송을 사용하며, WireGuard는 네트워크 계층 터널을 구성합니다. 프로토콜 항목에 WebSocket, Host, Path 또는 SNI가 있다면 외부 연결 조건도 확인해야 합니다. 이름만 보고 이 값을 추측하거나, 비슷해 보이는 다른 항목의 설정을 그대로 복사해서는 안 됩니다.

조건을 먼저 맞춘 뒤 성능을 비교하세요

실제로 선택할 수 있는 범위는 보유한 서버가 제공하면서 현재 클라이언트가 지원하는 설정으로 한정됩니다. 사용 가능한 항목이 하나뿐이라면 새로운 이름을 찾기보다 정확하게 입력하고 검증하는 것이 중요합니다. 여러 항목을 사용할 수 있다면 로컬 네트워크, 대상 사이트, 테스트 방법을 고정한 다음 연결 성공률, 첫 콘텐츠가 표시되는 시간, 연속 전송 성능 및 백그라운드 동작을 확인하세요. 서버 위치, 부하, 대역폭과 중간 네트워크가 프로토콜 자체의 차이보다 더 큰 영향을 줄 수 있습니다. 서버가 다른 항목끼리 비교한 결과를 프로토콜 차이만으로 해석해서는 안 됩니다.

데이터 보안도 계층별로 판단해야 합니다. 프로토콜 연결이 암호화되어 있어도 대상 앱이 자체 보안 요구사항을 무시하는 것은 아닙니다. 대상 사이트의 HTTPS는 여전히 종단 간 신원 확인을 담당합니다. 반대로 일반 HTTP 또는 SOCKS5로 접속한다고 해서 프록시 접속 구간이 자동으로 암호화되는 것도 아닙니다. 정보를 확인할 때는 프록시 연결, 대상 사이트, 도메인 이름 확인의 세 구간을 구분하고 각 구간을 어떤 방식으로 보호하는지 살펴보세요. 자물쇠 아이콘이나 프로토콜 이름만으로 판단해서는 안 됩니다.

Global Routing은 프로토콜을 바꾸지 않습니다

Global Routing의 Config, Proxy, Direct는 트래픽 정책입니다. Config는 설정 파일의 규칙에 따라 요청을 처리하고, Proxy는 프록시 방식으로 트래픽을 처리하며, Direct는 직접 연결할 때 사용합니다. 이 옵션을 바꿔도 Shadowsocks가 Trojan으로 바뀌지 않으며, 누락된 인증 항목이 복구되지도 않습니다. 문제를 확인할 때 적절한 모드를 사용해 규칙의 영향을 분리한 뒤, 테스트가 끝나면 일상 설정으로 되돌리세요. 임시 설정이 계속 남지 않도록 주의해야 합니다. 자세한 절차는 가이드의 규칙 설명을 확인하세요.

이 페이지는 호환성과 설계상의 차이를 다루며 특정 프로토콜에 일률적인 순위를 매기지 않습니다. 프로토콜은 일부 네트워크 환경에서 전송 방식을 개선할 수 있지만 서버의 실제 대역폭을 늘리거나 무선 신호 불량 및 계정 만료를 해결하지는 못합니다. “올바른 연결을 설정할 수 있는가”와 “연결 후 현재 작업에 적합한가”를 별개의 문제로 나누어 보세요. 그래야 이어지는 각 장의 설정 설명을 제대로 활용할 수 있습니다.

Shadowsocks: 암호화 프록시 설정의 범위

Shadowsocks는 비교적 간결한 프록시 프로토콜로 연결을 전달하며, 클라이언트와 서버가 공유하는 인증 및 암호화 정보를 사용해 데이터를 처리합니다. 원격 네트워크 인터페이스가 아니며, 서버가 속한 네트워크의 모든 라우팅을 클라이언트에 맡길 필요도 없습니다. 일반적으로 중요한 정보는 서버 주소, 포트, 암호화 방식 및 비밀번호입니다. 항목이 많지 않아 보여도 모두 일치해야 합니다. 특히 주소와 비밀번호가 같다는 이유로 암호화 방식을 임의로 바꿔서는 안 됩니다.

암호화 방식은 취향에 따라 바꾸는 항목이 아닙니다

암호화 방식에 따라 데이터 형식과 키 처리 방식이 달라집니다. 흔히 사용하는 인증 암호화 방식은 본문을 숨길 뿐 아니라 데이터가 변조되었는지도 확인합니다. 클라이언트는 서버가 지정한 방식을 사용해야 합니다. 일부 최신 방식은 특정 형식의 키를 요구하므로 일반적인 짧은 비밀번호와 같은 것으로 보면 안 됩니다. 원본 정보에 긴 인코딩 문자열이 있다면 대소문자, 기호, 마지막 문자를 포함해 그대로 보존하세요. 외우기 쉽게 고치거나 공백 및 따옴표를 임의로 추가하지 마세요.

링크를 가져오면 직접 입력으로 인한 오류를 줄일 수 있지만, 인코딩된 모양만으로 설정이 올바르다고 판단할 수는 없습니다. 가져온 뒤에는 프로토콜 유형, 주소, 포트 및 암호화 방식이 기존 정보와 일치하는지 확인하세요. 인식되지 않는 링크라면 링크가 완전한지, 별도로 지원해야 하는 확장 항목이 포함되어 있는지 먼저 확인해야 합니다. 브라우저에 표시된 일부만 복사하거나 표시 이름을 인증 정보로 착각하지 마세요. 항목 이름은 알아보기 쉽게 붙이는 메모일 뿐, 일반적으로 서버 인증에는 사용되지 않습니다.

TCP와 UDP는 각각 별도로 확인해야 합니다

웹 연결은 보통 신뢰성 있는 전송에 의존하지만, 실시간 통신이나 일부 앱은 UDP를 사용할 수도 있습니다. Shadowsocks가 해당 트래픽을 처리할 수 있는지는 클라이언트 설정, 서버 지원, 중간 네트워크가 모두 충족되는지에 달려 있습니다. 웹페이지는 열리는데 특정 실시간 기능이 실패하더라도 비밀번호 오류라고 단정할 수 없습니다. 해당 기능이 사용하는 전송 방식을 확인한 다음 서버에서 필요한 전달 기능이 활성화되어 있는지, 로컬 네트워크가 해당 트래픽을 허용하는지 살펴보세요. 웹페이지에 한 번 접속한 결과는 그때의 경로가 작동했다는 것만 보여줍니다.

일부 설정에는 추가 전송 또는 플러그인 항목이 포함됩니다. 이는 서버 구성의 일부이며 모든 Shadowsocks 항목에 공통으로 필요한 것은 아닙니다. 주소, 포트, 비밀번호만으로 확장 기능이 포함된 연결을 재현할 수 있다고 단정할 수 없습니다. 현재 화면에 해당 입력란이 없다면 이름이 비슷한 항목을 억지로 찾아 입력하지 말고 설정 출처에 호환성을 확인하세요. 프로토콜 지원과 특정 확장 기능 지원은 별개입니다. 가져오기에 성공해도 모든 확장 기능이 실제로 사용된다는 보장은 없습니다.

iPhone에서 효율을 이해하는 방법

프로토콜 구조가 간결하면 추가 처리 부담을 줄이는 데 도움이 될 수 있지만, 모든 환경에서 더 빠르거나 배터리를 덜 쓰는 것은 아닙니다. 암호화 알고리즘의 처리 효율, 서버 성능, 연결 수, 무선 네트워크 재전송이 모두 결과에 영향을 줍니다. 웹페이지 열람과 파일의 연속 전송은 부하 특성이 다릅니다. 전자는 연결 설정 및 소규모 요청의 응답이 중요하고, 후자는 안정적인 처리량이 중요합니다. 대용량 파일 전송을 한 번만 비교하면 일상적으로 앱을 반복 연결할 때의 실제 사용감은 놓칠 수 있습니다.

배터리 사용량에서는 안정적인 소수의 연결을 유지하는 경우와 연결이 계속 실패해 재시도하는 경우의 차이가, 올바르게 설정된 두 구성 간 암호화 처리 비용의 차이보다 더 클 수 있습니다. 백그라운드 사용량이 크게 달라졌다면 항목이 계속 시간 초과되는지, On Demand가 반복해서 연결을 시작하는지, 네트워크 전환 후 연결이 복구되는지 먼저 확인하세요. “Shadowsocks 설정 항목이 적다”는 이유만으로 백그라운드 비용이 없다고 볼 수는 없습니다. 시스템에 기록된 모든 네트워크 활동을 프로토콜 자체의 소비량으로 간주해서도 안 됩니다.

문제 해결 순서는 간단하게 유지할 수 있습니다. 먼저 기존 항목이 만료되지 않았는지 확인하고, 암호화 방식과 비밀번호를 살펴본 다음 서버 접속 지점과 로컬 네트워크를 확인합니다. 마지막으로 규칙과 DNS 차이를 점검하세요. 한 번 실패한 뒤 암호화 방식, 포트, DNS를 동시에 바꾸지 마세요. 다시 작동하더라도 원인을 알 수 없습니다. 확인이 끝난 기준 설정을 보관해 두면 다음 구독 업데이트 후 서버 정보가 바뀐 것인지 직접 편집한 내용이 원인인지 구분하기 쉽습니다.

VMess와 VLESS: 인증과 외부 전송을 나누어 확인하기

VMess와 VLESS는 여러 전송 방식을 조합하는 서버 설정에서 자주 볼 수 있지만, 이름만 다른 동일한 유형은 아닙니다. VMess는 자체 인증 및 데이터 처리 방식을 정의하고, VLESS는 간결한 신원 및 요청 정보에 중점을 두며 연결 보호는 배포 환경의 보안 계층에 맡깁니다. 두 프로토콜 모두 UUID를 사용할 수 있지만, UUID가 같다는 이유만으로 서로 바꿔 쓸 수는 없습니다. 서버가 사용하는 프로토콜 유형, 전송 방식, 보안 설정을 클라이언트와 모두 일치시켜야 합니다.

프로토콜과 전송 방식을 구분해야 하는 이유

이러한 프로토콜은 다양한 전송 조합과 배포 방식을 지원하기 위해 사용되므로, 항목에는 “누가 연결하는가”뿐 아니라 “어떤 외부 경로로 도달하는가”도 포함될 수 있습니다. VLESS라고 표시된 두 항목도 외부 전송 방식은 완전히 다를 수 있습니다. WebSocket이 표시되면 Host와 Path를 확인하고, TLS가 표시되면 인증서 신원과 관련된 설정도 살펴보세요. 어느 한 계층이라도 맞지 않으면 실제 인증 단계에 도달하기 전에 연결이 끊길 수 있습니다.

UUID는 신원 식별자이지 웹사이트 주소나 임의로 정하는 기기 이름이 아닙니다. 기존 정보를 문자 단위로 그대로 복사하고 구분 기호를 바꾸거나 다른 항목의 값을 가져오지 마세요. VMess 인증은 시간에도 영향을 받으므로 기기 시간이 크게 어긋나 있다면 자동 설정을 복원한 뒤 다시 확인하세요. 시간 오류는 TLS 인증서의 유효기간 판단에도 영향을 줄 수 있습니다. VMess만의 문제는 아니지만 이러한 항목에서는 특히 먼저 점검할 가치가 있습니다.

VMess 호환성 정보 확인 방법

오래된 설정에는 추가 인증 호환 항목이 포함될 수 있으며, 새로운 설정은 다른 인증 규칙을 사용할 수 있습니다. 과거 가이드의 고정값을 모든 서버의 기본값으로 여기지 말고, “최신 설정”을 목표로 기존의 정상 항목을 임의로 수정하지도 마세요. 현재 서버가 제공하는 완전한 정보를 우선 사용하세요. 구독 설정과 수동 입력 결과가 다르다면 표시 이름이 아니라 실제 항목을 비교해야 합니다. 확실하지 않은 옵션은 정보 제공자에게 해당 서버에서의 의미를 확인하세요.

VMess의 데이터 보호를 외부 TLS와 혼동해서는 안 됩니다. 외부 TLS 사용 여부, 인증서 확인 방식, 중간 전달 경로는 각각 별도의 배포 조건입니다. 오류에 따라 인증 실패로 표시될 수도 있고 핸드셰이크나 경로 일치 단계에서 멈출 수도 있습니다. 오류 기록에 실패 단계가 나와 있다면 해당 단계의 항목부터 확인하세요. 단계가 명확하지 않아도 주소, 전송, 인증서, 인증 순으로 범위를 좁히고 암호화 옵션을 무작위로 바꾸지 마세요.

VLESS의 간결한 구조가 의미하는 것

VLESS 자체가 완전한 연결 암호화를 제공한다고 이해해서는 안 됩니다. 프로토콜 계층이 담당하는 일부 역할을 줄인 만큼 외부 보안 설정이 특히 중요합니다. 설정 정보가 TLS 또는 다른 지원되는 보안 방식을 지정한다면 클라이언트에서도 해당 조합을 사용해야 합니다. UUID와 포트만 남긴다고 전체 연결 설정이 복원되는 것은 아닙니다. Flow 같은 추가 항목이 있다면 현재 클라이언트와 서버가 동일한 조합을 지원하는지도 확인해야 합니다. 이름이 비슷하다는 사실만으로 호환성을 입증할 수는 없습니다.

Host, SNI, 서버 주소에는 같은 도메인 이름을 입력할 수도 있지만 각 역할은 다릅니다. 서버 주소는 네트워크 연결 대상이고, SNI는 TLS 핸드셰이크에서 서비스 이름을 선택하는 데 사용됩니다. Host는 외부 요청의 라우팅에 관여할 수 있으며, Path는 WebSocket 요청이 도달할 처리 경로를 지정할 수 있습니다. 여러 단계로 전달되는 환경에서는 각 값이 서로 달라도 반드시 오류인 것은 아닙니다. 모두 서버 도메인으로 통일하지 말고 원본 설정에서 각 항목에 지정된 용도를 기준으로 확인하세요.

실제 성능 차이는 구체적인 조합에서 나타납니다

직접 전송, WebSocket, 추가 보안 핸드셰이크는 연결 설정에 서로 다른 비용이 들 수 있지만, 연결이 안정적으로 유지되면 초기 비용의 영향은 줄어듭니다. 따라서 소규모 요청이 많은 작업과 장시간 전송은 서로 다른 결과를 낼 수 있습니다. VLESS의 간결한 구조가 VMess보다 항상 종단 간 속도가 빠르다는 뜻은 아닙니다. 서버 부하, 외부 전달 경로, 대상 사이트도 주요 제한 요소가 될 수 있습니다. iOS에서는 프로토콜 구조만으로 고정된 속도 결론을 내리지 말고 실제 사용하는 전체 설정을 비교하세요.

기존 정보에서 특정 전송 조합을 명시했다면 성능 최적화보다 먼저 해당 조합이 작동하는지 확인하세요. 연결이 성립한 다음 첫 접속, 반복 접속, 네트워크 전환 후의 동작을 각각 살펴보세요. 보안 설정을 조정하기 전에는 원래 항목을 보존해야 합니다. 인증서 확인을 끄는 것은 속도 개선 방법이 아닙니다. 관련 용어는 용어 매뉴얼에서 확인할 수 있지만, 최종 설정은 보유한 서버의 안내와 현재 앱에서 사용할 수 있는 옵션을 기준으로 해야 합니다.

Trojan, HTTP, SOCKS5: 프록시 접속의 보안 차이

이 프로토콜들은 모두 프록시 접속 방식으로 사용할 수 있지만 보안 계층과 인증을 처리하는 방식은 다릅니다. Trojan은 TLS 연결을 통해 프록시 요청을 전달하고 해당 비밀번호로 인증하도록 설계되었습니다. HTTP 프록시는 HTTP 방식으로 연결을 설정하거나 전달하며, SOCKS5는 보다 범용적인 프록시 요청 협상을 제공합니다. 먼저 서버가 실제로 어떤 접속 방식을 제공하는지 확인하고, 접속 구간이 암호화되는지 살펴보세요. 모두 웹페이지를 전달할 수 있다는 이유로 완전히 같은 방식이라고 보면 안 됩니다.

Trojan: 인증서 확인은 연결 조건입니다

Trojan 설정에는 주소, 포트, 비밀번호뿐 아니라 TLS 서비스 이름도 중요합니다. 서버 주소는 도메인이나 IP일 수 있지만 인증서는 일반적으로 특정 이름을 대상으로 발급됩니다. SNI는 TLS 핸드셰이크에서 서비스 이름을 전달하는 데 사용되고, 인증서 검증은 상대방의 신원이 예상과 일치하는지 추가로 확인합니다. 서로 관련은 있지만 같은 기능은 아닙니다. SNI를 입력했다고 인증서를 신뢰할 수 있는 것은 아니며, 임의의 도메인을 공통값처럼 사용할 수도 없습니다. 서버 정보에 명시된 이름을 사용하세요.

인증서 만료, 기기 시간 오류, 이름 불일치, 중간 인증서 체인 누락 등은 연결을 차단할 수 있습니다. 이런 경우 시스템 시간과 원본 설정을 확인하고, 필요하다면 서버 관리자에게 인증서 수정을 요청하세요. “안전하지 않은 연결 허용”과 같은 옵션은 신원 확인 범위를 바꾸므로 일반적인 호환성 개선이나 속도 향상 기능이 아닙니다. 검증을 끈 뒤 연결되더라도 문제를 진단하는 데 도움이 된 것일 뿐, 원인이 올바르게 해결된 것은 아닙니다. 일상 설정에서 해당 옵션을 켜 두어서는 안 됩니다.

비밀번호는 원본 정보에서 완전히 복사하고 끝부분의 줄바꿈과 공백에 주의하세요. 서버가 추가 전송 캡슐화를 사용한다면 관련 경로와 요청 항목도 함께 맞춰야 합니다. 모든 Trojan 서버가 같은 연결 형식을 사용한다고 가정하지 마세요. 각 항목의 자세한 설명은 Trojan 비밀번호, SNI 및 TLS 설정 안내에서 확인할 수 있습니다. 이 문서는 입력 원리를 설명하며 서버 정보나 보유한 설정의 구체적인 값을 제공하지 않습니다.

HTTP: 프록시 접속과 대상 HTTPS 구분하기

HTTP 프록시는 관리가 명확한 네트워크 환경에서 흔히 사용됩니다. HTTPS 대상에 접속할 때 프록시는 보통 CONNECT로 대상 주소까지 터널을 설정하고, 대상 앱은 자체 TLS 인증을 계속 수행해야 합니다. 하지만 대상 사이트가 HTTPS라고 해서 클라이언트와 프록시 사이의 제어 정보까지 별도의 TLS로 보호되는 것은 아닙니다. 서버에서 TLS가 적용된 프록시 접속 지점을 제공한다면 항목 유형이나 보안 설정이 실제 접속 방식과 일치하는지 확인하세요. 흔히 쓰는 포트 번호로 바꾸는 것만으로는 충분하지 않습니다.

프록시 사용자 이름과 비밀번호는 웹사이트 로그인 정보와 다릅니다. 인증에 실패하면 사용자 이름이 필요한지, 비밀번호가 정확한지, 계정에서 현재 접속을 허용하는지 먼저 확인하세요. 관리자가 명확히 안내하지 않는 한 브라우저 로그인 페이지의 정보를 프록시 인증에 사용하지 마세요. 일반 HTTP 프록시가 지원하는 기능은 배포 환경에 따라 달라집니다. 웹페이지 하나에 접속할 수 있다고 모든 앱 트래픽에 적합하다고 볼 수 없습니다. UDP가 필요한 작업은 별도로 확인해야 합니다.

SOCKS5: 범용 전달이 기본 암호화를 뜻하지는 않습니다

SOCKS5는 협상을 통해 대상 주소와 요청 유형을 지정하고, 도메인 형식의 대상 주소 및 관련 인증과 UDP 전달 기능을 지원할 수 있습니다. 그러나 프로토콜 자체를 암호화된 연결로 간주해서는 안 됩니다. 실제 배포 환경에 따라 인증 방식, 접속 가능한 대상, UDP 지원 범위가 제한될 수 있습니다. 해당 기능은 클라이언트와 서버가 모두 지원해야 사용할 수 있습니다. SOCKS5라는 이름만으로 서버가 특정 트래픽을 허용하는지, 접속 경로가 어떤 보호를 제공하는지 알 수 없습니다.

도메인 이름을 어디서 확인하는지도 중요한 차이입니다. 프로토콜이 도메인 전달을 지원하더라도 앱이나 로컬 DNS 처리 과정에서 먼저 IP 주소로 변환될 수 있습니다. 문제를 확인할 때는 Shadowrocket의 DNS 및 규칙 설정도 함께 살펴보세요. 프로토콜 설명만 보고 모든 DNS 조회가 원격에서 이뤄진다고 단정해서는 안 됩니다. 사이트 이름으로 접속하면 실패하지만 IP 주소에는 응답이 있다면 프록시 계정을 바꾸거나 인증 문제로 단정하기 전에 DNS 결과와 규칙 적용 여부를 확인하세요.

일상적인 작업에 사용할 방식은 기존 환경을 바탕으로 선택하세요. 서버가 Trojan을 제공한다면 인증서와 비밀번호를 먼저 정확히 확인하고, 관리 네트워크에서 HTTP나 SOCKS5를 제공한다면 관리 요구사항과 보안 범위를 살펴보세요. 간결해 보인다는 이유로 필요한 TLS를 생략하거나, 여러 이름을 시험하려고 기존 항목을 한꺼번에 바꾸지 마세요. iPhone·iPad에서는 맞지 않는 유형을 반복 시도하는 것보다 올바르고 안정적인 접속 방식을 사용하는 편이 속도와 배터리 사용량에 유리합니다.

WireGuard: 네트워크 계층 터널과 키 설정

WireGuard는 앞에서 다룬 프록시 요청용 프로토콜과 달리 네트워크 계층 데이터를 암호화된 터널로 전달하는 방식입니다. 비교적 간결한 프로토콜과 고정된 암호화 조합을 사용해 다양한 협상 옵션을 줄였습니다. 여러 암호화 방식 중에서 고를 필요는 적지만, 로컬 인터페이스, 상대방 신원, 라우팅 범위를 정확히 설정해야 합니다. 항목이 적어 보여도 네트워크 계획을 생략할 수는 없습니다. 주소, 키, 허용 범위가 함께 터널의 기능을 결정합니다.

Private Key와 Public Key의 역할

로컬 Private Key는 로컬 신원을 식별하고 보호하며, Public Key는 해당 상대방을 식별하는 데 사용됩니다. 서로 관련은 있지만 서로 바꿔 쓸 수 없는 정보입니다. 설정을 복사할 때 자신의 Public Key를 상대방 신원 항목에 입력하거나, 상대방의 Public Key를 로컬 Private Key로 사용하지 마세요. 원본 정보에 사전 공유 키가 포함되어 있다면 양쪽에서 동일하게 설정해야 합니다. 이 키는 메모용 항목이 아니며 연결이 불안정하다고 임의로 삭제해서도 안 됩니다.

로컬 Private Key는 민감 정보입니다. 문제를 확인할 때는 “원본 설정과 일치함”이라고 기록할 수 있지만, 전체 값을 공개된 토론에 올리거나 공개 스크린샷에 포함해서는 안 됩니다. 로컬 Private Key를 바꾸면 일반적으로 서버에서도 대응하는 신원 정보를 갱신해야 합니다. 클라이언트에서 새 키만 생성해도 기존 서버가 계속 연결을 허용하는 것은 아닙니다. 기기를 분실했거나 설정을 폐기해야 한다면 기존 서버 관리자가 상대방 권한을 처리하도록 하세요. 표시 이름만 바꾸는 것으로 해결되지 않습니다.

Endpoint, Address, Allowed IPs

Endpoint는 상대방의 접속 주소와 포트를 가리키고, 로컬 Address는 터널 내부에서 사용할 주소입니다. 두 항목의 용도는 다릅니다. 공용 접속 주소를 터널 주소란에 넣거나 내부 터널 주소를 외부 서버 접속 지점으로 사용하면 예상한 연결이 이루어지지 않습니다. 주소 종류도 실제 설정과 일치해야 합니다. 설정 정보에 한 종류의 주소만 있다면 다른 종류를 임의로 추가하지 마세요. DNS 항목은 일반적으로 이름 확인 방식을 지정하며 로컬 인터페이스 주소나 서버 Endpoint를 대신하지 않습니다.

Allowed IPs는 상대방이 전달할 수 있는 주소 범위와 관련되며 WireGuard의 라우팅 및 발신지 확인에도 관여합니다. Shadowrocket의 전체 처리 과정에서는 실제 트래픽 경로를 이해하기 위해 앱의 트래픽 정책도 함께 고려해야 합니다. 이를 웹사이트 도메인 규칙과 같은 것으로 단순화해서는 안 됩니다. 범위가 너무 좁으면 일부 대상에 터널로 접속할 수 없고, 너무 넓으면 기존 네트워크 계획과 달라질 수 있습니다. 관리자가 제공한 설정을 유지하고, “모든 트래픽을 가능하게 하겠다”는 이유로 임의로 범위를 확장하지 마세요.

모바일 네트워크의 연결 유지 및 복구

WireGuard는 UDP를 사용합니다. 모바일 기기가 Wi-Fi와 셀룰러 네트워크 사이를 전환하면 네트워크 매핑이 바뀔 수 있습니다. 프로토콜에는 상대방 주소 변경에 대응하는 설계가 있지만, 실제 복구는 새 통신이 도달할 수 있는지, 서버가 허용하는지, 로컬 네트워크에서 차단되지 않는지에 달려 있습니다. Persistent Keepalive는 필요한 경우 일부 네트워크 매핑을 유지하는 데 쓸 수 있지만 주기적인 통신이 추가됩니다. 모든 네트워크에 적합한 고정값은 없으므로 기존 배포 지침을 따르고 백그라운드 동작과 네트워크 전환을 확인하세요.

연결을 더 안정적으로 만들겠다고 Keepalive 간격을 지나치게 짧게 설정해서는 안 됩니다. 무선 네트워크에서는 소량의 주기적 데이터도 기기가 절전 상태에 들어가는 데 영향을 줄 수 있습니다. 네트워크가 안정적이고 매핑 유지가 필요하지 않다면 Keepalive를 추가해도 도움이 되지 않을 수 있습니다. 반대로 기존 설정에서 요구하는 Keepalive를 완전히 끄면 오랫동안 유휴 상태였다가 처음 요청할 때 실패할 수 있습니다. 문제가 확인된 조건에서만 설정을 검증하고, 유휴 후 복구가 나아지는지 기록하며 시스템의 배터리 사용량도 함께 살펴보세요.

MTU와 일부 연결 실패의 관계

터널 캡슐화에는 추가 공간이 필요하므로 경로가 처리할 수 있는 패킷 크기를 확인할 필요가 있습니다. MTU가 맞지 않으면 작은 요청은 성공하는데 큰 전송은 멈추거나 일부 사이트만 열리고 다른 사이트는 계속 대기할 수 있습니다. 하지만 이런 증상은 다른 원인으로도 발생할 수 있으므로 지연이 있다고 바로 MTU를 바꾸지 마세요. 원래 값과 서버 권장값을 확인하고 규칙, DNS, 신호 문제를 제외한 뒤 한 번에 이 항목 하나만 조정하세요. 이전 값으로 복원할 수 있도록 근거를 남겨 두세요.

검증은 핸드셰이크 여부만 확인하고 끝내면 안 됩니다. 핸드셰이크는 양쪽이 통신의 특정 단계를 완료했다는 뜻일 뿐입니다. 대상 네트워크, DNS, 실제 업무 요청도 확인해야 합니다. 핸드셰이크는 성공했지만 실제 통신이 되지 않으면 키를 반복해서 새로 만들기보다 터널 주소, 허용 범위, 서버 측 전달 조건을 먼저 살펴보세요. 이렇게 하면 신원 문제와 네트워크 계획 문제를 나누어 확인하고, 이미 올바른 설정을 불필요하게 바꾸지 않을 수 있습니다.

Hysteria2: QUIC 전송과 대역폭 설정

Hysteria2는 패킷 손실, 지연, 네트워크 변동이 있는 경로에서 전송 성능을 유지하는 문제를 고려해 설계되었습니다. UDP 기반의 QUIC 전송을 사용하며 이에 맞는 인증 및 보안 기능을 결합합니다. “네트워크 변동에 대응한다”는 것은 설계 방향이지 모든 네트워크에서 작동한다는 보장이 아닙니다. 로컬 네트워크에서 필요한 UDP 통신을 허용하지 않거나 서버 접속 지점에 도달할 수 없다면 프로토콜 이름을 바꿔도 기본적인 연결 조건을 우회할 수 없습니다.

UDP가 본질적으로 더 빠르다고 볼 수 없는 이유

UDP 자체는 신뢰성 있고 순서가 보장된 전송을 제공하지 않지만, 상위 프로토콜은 UDP 위에서 신뢰성 있는 데이터 스트림, 재전송, 혼잡 제어를 구현할 수 있습니다. Hysteria2의 성능은 안정성 처리를 모두 생략한 결과가 아니라 전체 전송 설계에서 나옵니다. 패킷 손실은 여전히 처리해야 하고 서버의 대역폭과 처리 능력에도 한계가 있습니다. 처리량이 높아지면 실제 전송량도 늘 수 있으므로 완료 시간뿐 아니라 같은 네트워크의 다른 작업에 큰 영향을 주는지도 비교하세요.

QUIC은 여러 스트림을 제공해 일부 스트림 간 대기 문제를 줄일 수 있지만, 무선 신호가 매우 약하거나 업로드가 혼잡하거나 네트워크 경로가 계속 바뀌면 각 스트림은 제한된 네트워크 자원을 공유합니다. “멀티 스트림 지원”이 개별 요청이 다른 요청의 영향을 전혀 받지 않는다는 뜻은 아닙니다. 일상적인 웹 탐색과 연속 다운로드는 중요하게 보는 지표도 다릅니다. 전자는 DNS 확인과 핸드셰이크의 영향을 받을 수 있고, 후자는 안정적인 대역폭이 더 중요합니다. 연속 다운로드 속도만 보여주는 결과로 모든 작업에 적합한 설정을 판단할 수는 없습니다.

인증, SNI, 인증서도 항목별로 확인하세요

주소, 포트, 인증 정보는 기본 연결의 성립 여부를 결정하고, TLS 설정은 상대방 신원 확인이 예상대로 이루어지는지 결정합니다. 설정 정보에 SNI가 지정되어 있다면 원래 값을 유지하고, 인증서 문제가 있으면 이름, 유효기간, 신뢰 체인을 차례대로 확인하세요. UDP 기반이라는 이유로 인증서 확인을 생략해도 되는 것은 아닙니다. 같은 서버 주소에서 다른 프로토콜이 작동하더라도 다른 접속 지점에 도달할 수 있다는 뜻일 뿐, 현재 UDP 접속 지점과 인증 정보가 올바르다는 증거는 아닙니다.

일부 서버는 추가 난독화 설정을 요구할 수 있습니다. 해당 설정은 서버와 일치해야 하며 많이 켤수록 좋은 것이 아닙니다. “연결 실패”만으로 누락된 설정이 원인이라고 판단할 수는 없습니다. 기존 정보를 먼저 확인해 명확한 요구사항이 있는지 살펴보세요. 현재 클라이언트 화면에 확장 옵션이 없다면 지원 범위를 확인하거나 기존 정보에서 호환된다고 명시한 설정을 사용하세요. 확장 비밀번호를 일반 인증란에 넣거나 비슷해 보이는 옵션을 임의로 조합해서는 안 됩니다.

대역폭 항목은 조건을 나타내며 원하는 성능을 지정하는 값이 아닙니다

업로드 및 다운로드 대역폭 설정은 전송 속도와 혼잡 제어에 영향을 줄 수 있으며, 실제 효과는 양쪽 설정과 협상 결과에 따라 다릅니다. 입력할 때는 단위와 방향을 확인하세요. 업로드는 보통 클라이언트에서 네트워크로 보내는 방향이고 다운로드는 반대입니다. 비트와 바이트는 서로 다른 단위입니다. 서버 안내와 실제 접속 가능한 대역폭에 맞춰 설정하고 값을 무조건 크게 입력하지 마세요. 실제보다 높은 값을 가정하면 큐가 쌓이고 패킷 손실이 늘어 다른 요청까지 느려질 수 있습니다.

셀룰러 네트워크의 사용 가능한 대역폭은 신호, 위치, 네트워크 부하에 따라 달라집니다. Wi-Fi의 외부 접속 성능도 라우터에 표시된 무선 연결 속도와 같지 않습니다. 따라서 한 번 측정한 최고 속도를 장기 설정의 기준으로 삼지 마세요. 기존 정보에서 수동 설정을 요구하지 않는다면 적절한 원래 설정을 유지하고 현재 협상 방식을 먼저 확인하세요. 값을 조정한 뒤에는 순간 속도만 보지 말고 연속 작업과 상호작용 작업을 모두 테스트해야 합니다. 비슷한 조건에서 반복해서 개선되어야 참고할 만한 결과입니다.

iOS에서의 배터리 사용량과 적용 환경

작업을 더 빨리 끝내면 기기가 더 일찍 낮은 활동 상태로 돌아갈 수 있습니다. 반면 지속적인 대량 전송, 재전송, 연결 유지는 처리 비용과 무선 통신량을 늘릴 수 있습니다. 두 영향이 함께 있으므로 Hysteria2를 항상 배터리 절약 또는 배터리 소모 방식으로 분류할 수는 없습니다. 장시간 전송에서는 전체 완료 시간과 기기 발열을 확인하고, 백그라운드 유휴 상태에서는 지속 통신이나 재연결이 있는지 살펴보세요. 두 환경을 따로 테스트해야 결과를 혼동하지 않습니다.

기존 서버가 이 프로토콜을 제공하고 현재 네트워크에서 필요한 UDP 통신이 가능하다면 실제 작업으로 비교해 볼 수 있습니다. 특정 네트워크에서만 실패한다면 해당 네트워크 조건을 먼저 확인하고, 모든 네트워크에서 실패한다면 인증, 인증서, 서버 접속 지점을 다시 살펴보세요. 속도 문제를 자세히 확인하려면 인터넷 속도 저하의 계층별 문제 해결을 참고하세요. 올바른 연결이 성립하기 전에는 대역폭 설정을 최적화하지 마세요.

속도와 배터리 사용량: 반복 가능한 비교 방법

프로토콜 구조를 통해 예상되는 처리 부담은 설명할 수 있지만, 특정 iPhone에서의 사용 경험을 순위로 정할 수는 없습니다. 한 번의 접속에도 로컬 무선 네트워크, DNS 확인, 프록시 접속 지점, 서버 전달, 대상 서비스가 관여합니다. 어느 단계에서든 병목이 생길 수 있으며 연결 테스트의 수치도 특정 측정 과정만 반영합니다. 속도 문제를 연결 설정, 첫 응답, 연속 전송, 실패 후 복구로 나누고 현재 작업에 맞는 항목을 확인하세요. 하나의 결과로 전체 경로를 평가하지 않는 것이 중요합니다.

변수를 고정해야 비교할 수 있습니다

같은 기기, 같은 네트워크, 같은 대상을 사용해 비슷한 조건에서 정상 작동이 확인된 항목을 비교하세요. 시작하기 전에 테스트와 관계없는 대량 전송을 멈춰 사진 동기화, 시스템 업데이트, 다른 앱이 대역폭을 차지하지 않게 하세요. 두 항목이 서로 다른 서버를 사용한다면 그 차이를 분명히 기록해야 합니다. 이 경우 비교 결과는 두 연결 구성의 차이이지 프로토콜만의 차이는 아닙니다. 대상 콘텐츠가 캐시되었는지도 기록하세요. 이후 접속이 다른 위치의 캐시를 읽었을 수 있습니다.

데이터를 보기 좋게 만들려고 진단을 짧은 간격으로 계속 실행하지 마세요. 측정 과정 자체가 데이터를 사용하고 서버 부하를 늘리며 기기의 활동 상태를 바꿀 수 있습니다. 먼저 실제 작업에서 문제를 재현한 뒤 원인을 좁히는 데 필요한 테스트만 몇 가지 실행하는 편이 테스트 목록을 계속 새로고침하는 것보다 효과적입니다. 첫 결과가 이상하면 같은 조건에서 다시 확인할 수 있지만 가장 좋은 결과만 남겨서는 안 됩니다. 성공과 실패, 네트워크 전환 조건을 기록하면 최고 속도 하나보다 문제를 찾는 데 더 도움이 됩니다.

Connectivity Test로 알 수 있는 범위

Connectivity Test 결과의 의미는 테스트 방식과 대상에 따라 달라집니다. 정상 결과는 해당 시점에 지정된 테스트 경로가 정해진 절차를 완료했다는 뜻일 수 있지만, 모든 사이트 접속이나 충분한 연속 대역폭을 보장하지는 않습니다. 시간 초과가 발생해도 서버가 완전히 중단되었다고 단정할 수는 없습니다. 테스트 대상, DNS, 인증, 로컬 네트워크가 결과에 영향을 줄 수 있습니다. 테스트 기록은 실제 웹페이지나 업무 요청 결과와 함께 살펴보세요. 목록 정렬만으로 프로토콜의 우열을 정하지 마세요.

페이지에 콘텐츠가 표시되기까지 오래 걸린다면 DNS와 핸드셰이크를 먼저 확인하세요. 시작은 빠르지만 연속 전송이 느리다면 대역폭, 혼잡, 서버 부하를 살펴보세요. 특정 대상만 실패한다면 규칙 적용, 대상 서비스 상태, DNS 차이를 확인해야 합니다. 항목별 점검 순서는 노드 시간 초과 및 연결 실패 확인 목록을 참고하세요. 같은 증상도 원인이 되는 계층은 다를 수 있으므로 테스트는 문제 범위를 좁히는 데 활용해야 합니다.

배터리 사용량은 기기 활동과 함께 해석해야 합니다

iOS 배터리 사용량 화면에는 일정 기간의 앱 관련 활동이 기록되며, 표시 비율은 다른 앱의 사용량에도 영향을 받습니다. 프로토콜만의 전력 소비를 측정하는 도구는 아닙니다. 대량 다운로드, 연결 테스트, 백그라운드 전송을 많이 했다면 클라이언트 관련 사용량이 늘어나는 것은 자연스러울 수 있습니다. 비교할 때는 작업, 시간, 화면 상태, 네트워크 조건을 최대한 비슷하게 유지하세요. 기기가 뜨거워지는지, 연결 실패가 반복되는지, 배터리 소모가 화면을 켜고 조작할 때 발생했는지 백그라운드 유휴 상태에서 발생했는지도 살펴보세요.

무선 신호가 약하면 통신 비용이 크게 달라질 수 있으므로 안정적인 Wi-Fi와 불안정한 셀룰러 환경의 결과를 직접 비교해서는 안 됩니다. 암호화 처리에도 비용이 들지만 많은 모바일 작업에서는 무선 통신, 연속 전송, 기기의 반복적인 활성화도 중요한 요소입니다. 불필요한 연결 재시도를 줄이는 편이 이미 올바르게 설정된 암호화 항목을 바꾸는 것보다 실제 효과가 클 수 있습니다. 프로토콜 설정 항목이 적다는 사실만으로 배터리 영향을 추정하거나 일정한 사용 시간 개선을 약속할 수는 없습니다.

On Demand와 Keepalive는 서로 다른 기능입니다

On Demand는 특정 조건에서 연결을 시작하는 방식을 정하고, 프로토콜 Keepalive는 보통 기존 통신 관계나 네트워크 매핑을 유지하는 데 사용됩니다. On Demand는 서버 인증 오류를 해결하지 않으며, Keepalive도 올바른 요청 시 연결 규칙을 대신하지 못합니다. 문제가 있는 항목이 조건에 따라 계속 실행되면 연결이 반복될 수 있고, Keepalive가 지나치게 잦으면 유휴 상태에서도 통신이 발생할 수 있습니다. 문제를 확인할 때는 연결 시작 조건과 연결 후 동작을 따로 관찰하고 두 설정을 동시에 바꾸지 마세요.

백그라운드 문제는 On Demand 및 백그라운드 배터리 사용량 문제 해결도 함께 확인할 수 있습니다. 최종 선택은 자주 사용하는 작업에 적합해야 합니다. 안정적으로 열리고, 네트워크 전환 후 복구되며, 유휴 동작이 적절한지 먼저 살펴본 뒤 연속 전송 속도를 고려하세요. 드물게 하는 대용량 작업에서 성능이 뛰어나도 일상적인 웹 탐색에 가장 적합한 설정이라는 뜻은 아닙니다. 하나의 순위를 고집하기보다 사용 환경별로 검증된 항목을 보관하는 편이 실용적입니다.

입력 및 검증: 원본 정보에서 일상적인 Config까지

앞서 설명한 원리를 실제 작업에 적용할 때는 “원본 정보 보관, 유형 확인, 항목 대조, 연결 검증, 규칙 복원”의 다섯 단계로 진행할 수 있습니다. 앱을 처음 열 때의 전체 화면 절차는 반복하지 않으며 구체적인 조작 순서는 빠른 시작 가이드에서 확인하세요. 이 장에서는 항목을 추가할 수 있지만 가져오기가 완전했는지, 특정 항목을 비워도 되는지, 프록시 연결은 정상인데 일상 규칙이 실패하는 이유가 무엇인지 확인합니다.

가져온 뒤 먼저 확인하고 여러 항목을 한꺼번에 수정하지 마세요

보유한 Subscribe 정보를 사용할 때는 원본 출처를 보존하고 업데이트 후 항목이 예상한 그룹에 있는지 확인하세요. 표시 이름만으로 프로토콜과 서버가 같은지 알 수 없습니다. 구독으로 생성된 항목을 수동으로 수정하면 다음 업데이트에서 변경 내용이 덮어써질 수 있으므로 관리 방식을 이해해야 합니다. 시험할 항목이 있다면 원래 항목을 보존하고 구분하기 쉬운 테스트 기록을 만드세요. 구독 그룹 전체의 주소, 포트, 보안 옵션을 동시에 바꾸지 마세요.

구독 주소에는 접속 자격 정보가 포함될 수 있으므로 일반 링크처럼 보여도 민감 정보로 다뤄야 합니다. 전체 주소를 공개 스크린샷이나 오류 보고서에 올리지 마세요. 구조를 설명할 때는 명확한 예시 값만 사용하세요. 이 페이지에서는 실제 설정을 제출할 필요가 없습니다. 설정을 확인할 때는 유형, 인증, 외부 전송, 보안 항목이 모두 있는지 차례로 살펴보고 복사 과정에서 줄바꿈이나 공백이 들어갔거나 내용이 잘리지 않았는지도 확인하세요.

실패 단계에 따라 점검할 항목을 선택하세요

서버 접속 지점에 도달하지 못한다면 주소, 포트, 현재 네트워크를 먼저 확인하세요. TLS 또는 인증서 오류가 나타나면 시간, 이름, 신뢰 체인을 살펴보세요. 인증 단계에서 실패한다면 비밀번호, UUID, 키를 확인합니다. 연결은 성립했지만 대상에 접속할 수 없다면 DNS, 규칙, 서버 전달, 대상 서비스 상태를 점검해야 합니다. 오류 기록에 항상 실패 단계가 명확히 표시되는 것은 아니지만, 인증서 오류가 분명한데 비밀번호를 계속 바꾸는 일을 막는 데 도움이 되는 순서입니다.

특정 네트워크에서만 실패한다면 같은 항목을 유지한 채 두 네트워크에서 각각 확인하세요. 특정 대상에서만 실패한다면 같은 네트워크에서 다른 대상을 확인합니다. 한 번에 조건 하나만 바꿔야 결론을 다시 검증할 수 있습니다. 시스템 알림과 앱 기록이 서로 맞지 않는다면 테스트 시각과 현재 실제 선택된 항목부터 확인하세요. 여러 번 편집한 뒤에는 이름이 비슷한 복사본을 혼동하기 쉽습니다. 목록에서의 위치로 판단하지 말고 설정 항목과 그룹을 확인하세요.

설정을 쌓아 올리지 말고 짧은 규칙으로 정책을 확인하세요

프로토콜 연결이 정상이라면 Global Routing을 일상적으로 사용할 Config로 복원하세요. 아래는 Shadowrocket 설정에서 살펴볼 수 있는 짧은 규칙 예시로, 순서와 정책을 설명하기 위한 것이며 완전한 설정은 아닙니다. 예시 도메인은 서비스를 추천하는 의미가 아닙니다. PROXY와 DIRECT의 실제 동작은 선택한 항목 및 현재 설정과 함께 검증해야 합니다. 이 부분을 알 수 없는 위치에 추가했다고 바로 적용되는 것은 아닙니다. Config에서 예상한 파일을 사용 중인지 확인하세요.

[Rule]
DOMAIN-SUFFIX,example.com,PROXY
GEOIP,CN,DIRECT
FINAL,PROXY

첫 번째 규칙은 도메인 접미사로 매칭하고 두 번째는 지리적 IP 조건으로 매칭합니다. 마지막 규칙은 앞선 조건에 일치하지 않는 요청에 최종 정책을 적용합니다. 규칙은 보통 순서대로 처리되므로 더 구체적인 조건이 올바르게 적용되도록 적절한 위치에 배치해야 합니다. 여기서 FINAL,PROXY를 선택한 것은 문법을 보여주기 위한 것이며, 나머지 모든 트래픽을 프록시로 보내야 한다는 뜻은 아닙니다. 지정된 사이트만 처리하려면 최종 정책을 다시 확인하고 특정 사이트의 DOMAIN-SUFFIX 설정 안내를 참고하세요.

종료 조건과 복원 방법 확인

한 차례의 전체 검증에는 실제 작업, 규칙 적용, 유휴 후 복구, 자주 발생하는 네트워크 전환이 포함되어야 합니다. 설정이 올바르다는 것을 증명하려고 관련 없는 대상을 많이 방문하거나 테스트를 계속 실행할 필요는 없습니다. 평소 작업을 안정적으로 마칠 수 있다면 시험을 위한 변경을 중단하고 필요한 일상 정책을 복원한 뒤 유지할 설정을 기록하세요. 테스트가 실패하면 방금 바꾼 항목 하나를 되돌리고 다음 점검 단계로 넘어가세요. 임시 변경을 계속 쌓지 않는 것이 중요합니다.

기존 서비스 제공자나 서버 관리자에게 문의할 때는 프로토콜 유형, 실패 단계, 네트워크 조건, 민감 정보를 제거한 오류 설명을 제공하면 됩니다. 실제 비밀번호, Private Key, 전체 구독 주소, 개인 접속 기록은 반드시 삭제하세요. 구매, 구매 항목 복원, App Store 호환성 문제라면 구매 항목 복원 안내와 해당 페이지의 자주 묻는 질문을 확인하세요. 계정 구매 문제와 프로토콜 인증 문제를 혼동하지 마세요. 시스템 요구사항 및 구매 가능 범위는 App Store 페이지에 표시된 내용을 기준으로 합니다.

프로토콜 참고의 목적은 이름을 계속 바꾸도록 권하는 것이 아니라 문제를 올바른 계층에서 찾도록 돕는 것입니다. 주소와 인증은 접속을 담당하고, 보안 계층은 상대방 신원을 확인하며, 전송 방식은 데이터 전달 경로에 영향을 주고, Config는 요청이 향하는 곳을 결정합니다. 이 흐름에 따라 각 계층을 차례로 확인하면 “비슷해 보이는 연결 실패”를 점검 가능한 작은 문제로 나눌 수 있습니다. 구독을 업데이트하거나 기기를 바꾼 뒤에도 명확하게 확인하고 복원할 수 있는 사용 환경을 유지할 수 있습니다.