VPN 초보자 가이드에서 가장 중요한 것은 약어를 외우는 일이 아니라 클라이언트의 각 옵션이 어느 단계에 해당하는지 이해하는 것입니다. 구독은 설정을 전달하고, 노드는 연결 가능한 출구를 나타내며, 프로토콜은 데이터 전송 방식을 정합니다. 회선 유형은 데이터가 통과하는 네트워크 경로를 설명하고, 분할 라우팅 규칙은 어떤 요청을 프록시로 보낼지 결정합니다. 각 계층을 나누어 이해하면 회선 선택, 가져오기, 문제 해결이 훨씬 쉬워집니다.
자주 쓰는 용어빠른 확인
아래 표에서 먼저 핵심 정의를 확인해 보세요. 연결 문제가 생기면 모든 설정을 무작정 바꾸기보다 ‘구독 업데이트 여부, 노드 사용 가능 여부, 프로토콜 호환성, 규칙 일치 여부, DNS 일관성’ 순서로 원인을 좁히는 것이 좋습니다.
| 용어 | 실제 의미 | 흔한 오해 | 확인할 사항 |
|---|---|---|---|
| 구독 링크 | 클라이언트가 노드, 프로토콜 매개변수와 일부 규칙을 가져오는 설정 주소 | 구독 링크가 이미 연결된 회선이라고 생각하는 것 | 가져오기 위치, 업데이트 상태와 링크 보안 |
| 노드 | 클라이언트가 실제로 연결하는 원격 서버 진입점 | 같은 지역의 노드는 사용 경험도 반드시 같다고 생각하는 것 | 회선 경로, 부하 변화와 대상 서비스 지역 |
| 프로토콜 | 클라이언트와 노드 간 전송, 인증과 암호화에 사용하는 규칙 | 프로토콜 이름을 속도 등급과 동일하게 보는 것 | 클라이언트 호환성, 네트워크 환경과 전송 방식 |
| 직결 회선 | 로컬 네트워크에서 공용 인터넷을 통해 원격 노드에 직접 연결하는 방식 | ‘직결’을 프록시를 거치지 않는다는 뜻으로만 이해하는 것 | 네트워크 간 라우팅, 저녁 시간대 변동과 진입점 접근성 |
| 중계 회선 | 가까운 진입점에 먼저 연결한 뒤 중계 네트워크를 통해 출구로 전달하는 방식 | 중계 홉이 늘면 반드시 느려진다고 생각하는 것 | 진입점 품질, 중계 경로와 출구 안정성 |
| IEPL | 기업의 국제 통신에 자주 사용되는 국제 이더넷 전용 회선 유형 | 회선 이름 자체가 전송 암호화를 대신한다고 생각하는 것 | 서비스 제공자의 실제 구현, 진입점 연결과 프로토콜 설정 |
| 분할 라우팅 | 도메인, 주소, 앱 또는 규칙 세트에 따라 트래픽 경로를 정하는 방식 | 규칙 모드를 켜면 모든 앱이 자동으로 올바르게 인식된다고 생각하는 것 | 규칙 우선순위, 미일치 정책과 DNS 처리 |
| 전체 모드 | 클라이언트가 관리하는 트래픽을 기본적으로 프록시를 통해 보내는 방식 | 기기의 모든 네트워크 요청을 반드시 처리한다고 생각하는 것 | 시스템 프록시, TUN 관리 범위와 앱 예외 |
구독 링크 가져오기와 업데이트 방법
구독 링크는 보통 웹 주소 형태로 제공되는 설정 진입점입니다. 클라이언트가 이 주소에 접속하면 노드 이름, 서버 주소, 포트, 인증 정보, 프로토콜 매개변수와 서비스에서 제공하는 기타 설정을 읽습니다. 클라이언트마다 같은 구독을 해석하는 능력이 다를 수 있으므로 ‘브라우저에서 링크가 열린다’와 ‘클라이언트가 올바르게 가져온다’는 별개의 문제입니다.
구독 주소에는 개인 설정을 읽는 데 사용할 수 있는 인증 정보가 포함되는 경우가 많으므로 비밀번호처럼 보관해야 합니다. 공개 문서, 공개 코드 저장소나 스크린샷에 올리지 마세요. 기기를 바꿀 때는 출처가 불분명한 전달본보다 서비스 패널에서 다시 복사하는 것이 좋습니다. 서비스 패널에서 구독 재설정을 지원한다면 링크가 실수로 노출된 즉시 업데이트하세요.
- 서비스 패널에서 현재 클라이언트에 맞는 구독 링크를 복사하고, 불필요한 공백이나 줄바꿈이 없는지 확인합니다.
- 클라이언트의 구독, 설정 또는 원격 설정 화면으로 이동해 링크에서 가져오기를 선택합니다. 개별 노드 편집창에 붙여넣지 마세요.
- 구독 업데이트를 실행하고 노드 목록이 로드될 때까지 기다린 다음, 노드 이름과 프로토콜 유형이 정상적으로 표시되는지 확인합니다.
- 현재 용도에 맞는 노드를 선택하고 시스템 프록시 또는 TUN을 활성화한 뒤 접속을 테스트합니다.
- 이후 노드 정보가 바뀌면 ‘구독 업데이트’를 사용하세요. 같은 구독을 반복해서 새로 만들면 목록이 중복될 수 있습니다.
노드 목록이 비어 있을 때 확인할 사항
구독 업데이트가 성공했다고 표시되지만 목록이 비어 있다면 클라이언트가 응답 형식을 해석하지 못했거나 필터가 모든 노드를 숨기고 있을 수 있습니다. 업데이트에서 네트워크 오류가 바로 발생한다면 구독 주소 접근 불가, 인증서 검증 실패, 로컬 네트워크 차단을 구분해야 합니다. 인증서 검증은 예상한 서버에 연결했는지 확인하는 기능이므로 의미를 이해하지 못한 채 끄지 마세요.
구독과 단일 노드 설정의 차이
단일 노드 설정은 하나의 연결 진입점만 설명하므로 임시 가져오기나 특정 회선 점검에 적합합니다. 구독은 여러 노드를 한 번에 업데이트하기 쉽고 그룹과 규칙이 포함될 수도 있습니다. 구독으로 생성된 노드를 수동으로 수정하면 다음 업데이트에서 변경 사항이 덮어써질 수 있습니다. 장기간 유지할 사용자 지정 규칙은 원격 내용을 직접 수정하지 말고 클라이언트가 지원하는 재정의, 스크립트 또는 로컬 규칙 영역에 저장하세요.
노드, 진입점과 출구는 서로 다릅니다
클라이언트의 노드 이름에는 보통 지역, 회선 유형이나 용도 안내가 포함되지만 이름은 어디까지나 라벨입니다. 실제 사용 경험에 영향을 주는 것은 로컬 네트워크에서 진입점까지의 경로, 진입점에서 출구까지의 전송 방식, 그리고 출구에서 대상 서비스까지의 네트워크 품질입니다. 특정 지역으로 표시된 노드는 대개 대상 서비스에 접속할 때 해당 지역의 출구 주소를 사용한다는 뜻이며, 전체 경로가 그 지역에 있다는 의미는 아닙니다.
진입점은 클라이언트가 처음 연결하는 위치이고, 출구는 대상 웹사이트에 표시되는 출발 위치입니다. 직결 노드는 진입점과 출구가 같은 서버일 수도 있고 서비스 내부에서 전달될 수도 있습니다. 중계 회선은 보통 가까운 진입점에 먼저 접속한 뒤 다른 지역의 출구로 전달합니다. 클라이언트 화면에 이러한 내부 구조가 모두 표시되지는 않으므로 노드 이름만으로 전체 토폴로지를 추측해서는 안 됩니다.
- ✅ 일반 웹페이지에 접속할 때는 현재 네트워크와 가깝고 라우팅이 안정적인 진입점을 우선 선택하세요.
- ✅ 지역 제한이 있는 서비스를 이용할 때는 출구 지역과 계정에서 주로 사용하는 지역이 일치하는지 함께 확인하세요.
- ✅ 장시간 연결이 자주 끊긴다면 같은 지역의 노드 이름만 바꾸기보다 서로 다른 회선 유형을 먼저 비교하세요.
- ✅ 노드를 바꾼 뒤에는 앱 연결을 다시 수립해 기존 연결이 이전 출구를 계속 사용하지 않도록 하세요.
- ❌ 노드 이름의 ‘고속’이나 ‘전용 회선’을 현재 네트워크에서 측정한 실제 결과로 바로 받아들이지 마세요.
지연 시간이 낮으면 반드시 더 빠를까
지연 시간은 한 번 왕복하는 데 걸리는 시간을 나타내지만 웹페이지 로딩, 파일 전송과 스트리밍은 대역폭, 혼잡, 패킷 손실, 서버 응답과 연결 재사용의 영향도 받습니다. 클라이언트의 지연 시간 테스트는 진입점만 확인할 수 있어 출구에서 대상 서비스에 접속하는 성능을 보여주지 않을 수도 있습니다. 노드를 선택할 때는 실제 사용 환경에서 테스트하세요. 웹은 첫 화면 응답, 회의는 음성의 연속성, 개발 도구는 장시간 연결의 반복 재연결 여부를 확인하면 됩니다.
노드를 바꿨는데 지역이 바뀌지 않는 이유
앱이 기존 연결을 유지하고 있거나 브라우저가 별도의 프록시 설정을 사용하고 있을 수 있습니다. 또는 분할 라우팅 규칙 때문에 조회 요청이 직결로 처리되었을 수도 있습니다. 먼저 관련 앱을 완전히 종료한 뒤 클라이언트의 현재 노드, 프록시 모드와 IP 조회 결과를 확인하세요. 특정 앱만 문제가 있다면 시스템 프록시를 우회하는지, 자체 보안 DNS와 프록시 확장 기능을 사용하는지 점검하세요.
Shadowsocks, VMess, Trojan 등 프로토콜 이해하기
프로토콜은 클라이언트가 서비스 서버와 신원을 협상하고 데이터를 캡슐화해 전송하는 방식을 정합니다. 프로토콜 이름이 회선 품질을 의미하는 것은 아닙니다. 같은 네트워크 경로에서도 프로토콜에 따라 결과가 다를 수 있고, 같은 프로토콜도 경로에 따라 차이가 커질 수 있습니다. 선택할 때는 먼저 서버가 제공하는 항목을 확인하고, 클라이언트가 해당 전송 매개변수를 완전히 지원하는지 살펴보세요.
Shadowsocks
Shadowsocks는 암호화 프록시 프로토콜로, 설정에는 보통 서버, 포트, 비밀번호와 암호화 방식이 포함됩니다. 구조가 비교적 단순하고 지원하는 클라이언트가 많지만 구현마다 지원하는 암호화 스위트가 완전히 같지는 않습니다. 가져온 뒤 암호화 방식이 지원되지 않는다는 메시지가 나오면 클라이언트 코어를 업데이트하거나 서비스에서 권장하는 클라이언트를 사용하세요. 서버 매개변수와 일치해야 하므로 임의로 다른 방식으로 바꾸지 마세요.
VMess와 VLESS
VMess는 V2Ray 생태계에서 자주 사용되며 서버와 인증 정보 외에 전송 계층, 경로, 호스트 이름과 TLS 등의 매개변수가 포함될 수 있습니다. VLESS는 더 간결한 인증 방식을 사용하고 자체적으로 콘텐츠 암호화를 담당하지 않으므로 실제 구축에서는 보통 TLS 같은 보안 전송 방식과 함께 사용합니다. 두 프로토콜은 형태가 비슷해도 서로 대체할 수 없습니다. 전송 계층 필드가 하나라도 다르면 핸드셰이크가 실패할 수 있습니다.
Trojan
Trojan은 보통 TLS 위에서 실행되며 인증서 도메인, 서버 이름 표시와 서버 설정이 서로 일치해야 합니다. 인증서 오류가 발생하면 검증을 바로 끄기보다 기기 시간, 도메인과 구독 매개변수를 먼저 확인하세요. 서버에 연결된다고 해서 TLS 신원 검증까지 성공했다는 뜻은 아닙니다.
Hysteria2와 TUIC
Hysteria2와 TUIC는 모두 QUIC 및 UDP 전송을 중요한 기반으로 하며, 패킷 손실이나 대역폭 변동이 있는 네트워크에서 기존 TCP 방식과 다른 결과를 보일 수 있습니다. 다만 일부 사무실 네트워크, 공용 네트워크나 라우터는 UDP를 제한합니다. 이때 핸드셰이크 실패, 연결 직후 중단 또는 TCP 방식보다 뚜렷한 성능 저하가 나타날 수 있습니다. 이런 경우 문제를 노드 지역 탓으로 돌리기보다 TCP 기반의 사용 가능한 프로토콜로 바꿔 비교하세요.
IEPL, 중계와 직결 회선의 차이
회선 유형은 로컬 네트워크에서 원격 출구까지 데이터가 이동하는 경로를 설명합니다. 직결은 보통 클라이언트가 공용 인터넷을 통해 원격 서버에 직접 접속하는 방식으로 경로가 단순하지만, 통신사 간·지역 간 라우팅은 시간대에 따라 바뀔 수 있습니다. 중계는 먼저 진입점에 연결한 뒤 서버가 이후 경로를 정합니다. 로컬 접속에 더 적합한 진입점을 선택하고 국제 구간을 조정할 수 있다는 점이 장점입니다.
IEPL은 국제 이더넷 전용 회선 서비스 유형으로, 기업 네트워크 간 국제 연결에 자주 사용됩니다. 가속 서비스 노드 이름에 IEPL이 표시된다면 일부 전송 경로가 해당 전용 회선 자원을 사용한다는 뜻일 수 있지만, 실제 접속 범위는 서비스 제공자의 구현에 따라 달라집니다. IEPL은 회선을 설명하는 용어이지 프로토콜 암호화를 대신하지 않으며, 라벨만으로 로컬 접속 구간, 출구 구간 또는 대상 웹사이트의 상태를 판단할 수 없습니다.
| 회선 유형 | 연결 방식 | 관찰하기 좋은 상황 | 흔한 제한 사항 |
|---|---|---|---|
| 직결 | 로컬 공용 인터넷에서 원격 노드로 직접 연결 | 일반적인 웹 이용, 가까운 경로, 현지 네트워크의 양호한 직접 연결 품질 | 네트워크 간 우회나 혼잡 시 변동이 커질 수 있음 |
| 중계 | 로컬에서 먼저 진입점으로 이동한 뒤 출구로 전달 | 장시간 연결, 통신사 간 접속, 안정적인 진입점이 필요한 상황 | 진입점이나 중계 구간에 문제가 생기면 전체 연결에 영향을 줌 |
| IEPL | 일부 경로에서 국제 이더넷 전용 회선 자원을 사용 | 기업 협업, 회의, 개발 연결처럼 연속성이 중요한 상황 | 실제 적용 범위는 서비스 설정을 기준으로 확인해야 함 |
회선을 판단할 때 속도 측정을 한 번만 실행하지 마세요. 짧은 다운로드는 연결 끊김을 가릴 수 있지만 지속적인 세션에서는 문제가 더 쉽게 드러납니다. 웹페이지 최초 접속, 연속 요청, 파일 전송과 실시간 통화를 각각 관찰해 보세요. 특정 대상 서비스만 이상하다면 전체 회선이 끊겼다고 바로 판단하기보다 대상 서비스 자체의 라우팅이나 지역 제한도 고려해야 합니다.
분할 라우팅, 규칙 모드와 전체 모드
분할 라우팅은 ‘어떤 트래픽을 프록시로 보낼지’를 결정합니다. 규칙은 도메인, 주소 범위, 앱 프로세스나 기타 조건과 일치시킬 수 있습니다. 프록시 규칙에 해당하는 요청은 노드로 보내고, 직결 규칙에 해당하는 요청은 직접 접속하며, 어느 규칙에도 맞지 않는 요청은 최종 규칙으로 처리합니다. 규칙 순서는 중요합니다. 클라이언트는 일반적으로 앞에서부터 일치 여부를 확인하므로, 범위가 넓은 규칙을 너무 앞에 두면 뒤의 정밀한 규칙이 적용되지 않을 수 있습니다.
규칙 모드
규칙 모드는 일상적인 사용에 적합합니다. 자주 이용하는 로컬 서비스는 직결하고 국제 회선이 필요한 요청만 프록시로 보내 불필요한 우회를 줄이며 서비스별 출구도 유지할 수 있습니다. 다만 결과는 규칙 세트가 최신인지, DNS 조회가 규칙 판단과 일치하는지에 따라 달라집니다. 도메인이 올바르게 해석되지 않으면 규칙을 정확히 작성해도 예상한 정책이 적용되지 않을 수 있습니다.
전체 모드
전체 모드는 보통 클라이언트가 관리하는 트래픽을 기본적으로 프록시로 보내며, 규칙 문제를 확인할 때 유용합니다. 규칙 모드에서는 열리지 않지만 전체 모드에서는 열린다면 노드와 프로토콜은 대체로 작동하고, 문제는 도메인 규칙, 주소 규칙이나 DNS에 있을 가능성이 큽니다. 시스템 프록시 모드는 시스템 프록시를 따르는 앱에만 영향을 주므로 이를 읽지 않는 프로그램은 여전히 직결될 수 있습니다.
직결 모드
직결 모드는 프록시를 우회하므로 로컬 네트워크 자체가 정상인지 확인할 때 사용할 수 있습니다. 직결과 프록시 모두 대상에 접속하지 못한다면 먼저 기기 네트워크, 도메인 해석과 대상 서비스 상태를 점검하세요. 직결은 정상인데 프록시만 문제가 있다면 노드, 프로토콜과 회선을 확인해야 합니다. 직결 모드를 비교 기준으로 남겨 두면 클라이언트를 반복해서 재설치하는 것보다 원인을 쉽게 찾을 수 있습니다.
- ✅ 일상적인 사용은 먼저 규칙 모드를 선택하고 자주 쓰는 서비스가 예상한 회선으로 각각 이동하는지 확인하세요.
- ✅ 특정 웹사이트에 문제가 생기면 전체 모드로 비교해 규칙 문제인지 판단하세요.
- ✅ 특정 앱이 전혀 영향을 받지 않는다면 시스템 프록시를 지원하는지 확인하고, 필요하면 TUN을 테스트하세요.
- ✅ 모드를 바꾼 뒤 앱을 다시 열어 기존 연결이 이전 라우팅을 계속 사용하지 않도록 하세요.
- ❌ 여러 클라이언트가 동시에 시스템 프록시를 관리하도록 설정하지 마세요. 설정이 서로 덮어쓸 수 있습니다.
DNS 누출과 도메인 해석이 분할 라우팅에 미치는 영향
DNS는 도메인을 네트워크 주소로 변환합니다. DNS 누출은 보통 프록시 환경에서 처리되어야 할 도메인 조회가 로컬 네트워크의 DNS 서버로 전송되는 현상을 뜻합니다. 이로 인해 조회 의도가 노출되거나 프록시 출구와 맞지 않는 결과가 반환되어 지역 판단 오류, 규칙 오판이나 접속 실패가 발생할 수 있습니다.
웹 트래픽만 노드를 거치게 한다고 DNS까지 함께 노드를 통과하는 것은 아닙니다. 브라우저의 보안 DNS, 운영체제 리졸버, 클라이언트 내장 DNS와 라우터 설정이 동시에 관여할 수 있습니다. 문제를 확인할 때는 누가 해석하는지, 조회가 어떤 경로로 전송되는지, 반환 결과가 분할 라우팅 모듈에서 사용되는지를 명확히 파악해야 합니다. 클라이언트마다 이를 원격 DNS, 프록시 DNS, Fake IP 또는 강화 모드라고 부를 수 있으므로 구체적인 동작은 해당 클라이언트 문서를 기준으로 확인하세요.
Fake IP 모드는 먼저 도메인에 로컬 매핑용 가상 주소를 할당한 뒤, 클라이언트가 연결을 받으면 원래 도메인에 따라 규칙을 적용하고 전달합니다. 도메인 정보를 유지하는 데 도움이 되지만 일부 로컬 네트워크 서비스, 게임이나 특수 앱과 호환되지 않을 수 있어 예외를 추가해야 합니다. 실제 주소 모드는 해석 결과를 바로 반환해 전통적인 네트워크 동작에 가깝지만, 해석 경로와 캐시 일관성에 주의해야 합니다.
플랫폼별 클라이언트 차이 확인하기
클라이언트 이름이 다르다고 해서 기본 기능이 완전히 다른 것은 아니며, 이름이 같다고 해서 플랫폼별 기능이 같은 것도 아닙니다. Windows와 macOS에서는 시스템 프록시와 TUN이라는 두 가지 관리 방식이 흔하지만 가상 네트워크 카드 권한, 시스템 확장 기능과 절전 후 복구 동작은 다릅니다. Android는 보통 시스템이 제공하는 VPN 인터페이스로 트래픽을 관리하고 앱별 분할 라우팅을 설정할 수 있습니다. iOS도 시스템 네트워크 확장 기능에 의존하며 백그라운드 정책과 사용 가능한 코어가 플랫폼의 제한을 받습니다.
데스크톱 플랫폼은 상세 로그, 라우팅 테이블과 연결 통계를 확인하기에 적합하고, 모바일 플랫폼은 배터리 절약과 네트워크 전환을 더 중요하게 다룹니다. 기기가 Wi-Fi에서 모바일 네트워크로 전환되면 기존 연결이 끊길 수 있어 클라이언트가 다시 핸드셰이크해야 합니다. 모바일에서 ‘화면에는 연결됨으로 표시되지만 앱에 접속할 수 없는’ 경우 먼저 연결을 끊었다가 다시 연결한 뒤 앱별 프록시와 로컬 네트워크 권한을 확인하세요.
명령줄 도구에서는 환경 변수도 별도로 확인해야 합니다. 터미널의 Git, 패키지 관리자나 개발 도구가 데스크톱 클라이언트 설정을 자동으로 읽는 것은 아닙니다. 일부 도구는 시스템 프록시를 사용하고, 일부는 HTTP_PROXY 또는 HTTPS_PROXY를 읽으며, 일부는 SOCKS 주소가 필요합니다. 환경 변수는 해당 변수를 설정한 프로세스와 자식 프로세스에만 적용되므로 변경 후에는 보통 터미널을 다시 열어야 합니다.
클라이언트 선택 시 확인할 항목
- ✅ 구독에 실제로 제공된 프로토콜과 전송 계층 매개변수를 지원하는지 확인하세요.
- ✅ 원격 구독을 업데이트할 수 있고 원격 설정과 로컬 재정의를 명확히 구분하는지 확인하세요.
- ✅ 규칙 일치, 연결 오류나 기본 로그를 제공해 문제 해결을 지원하는지 확인하세요.
- ✅ 사용 환경에 맞는 관리 방식을 제공하고, 독립 앱까지 처리해야 한다면 TUN을 사용할 수 있는지 확인하세요.
- ✅ DNS 설정과 분할 라우팅 엔진이 함께 작동하는지 확인하세요.
- ❌ 출처가 불분명한 페이지에서 수정된 클라이언트를 다운로드하거나 낯선 설정을 가져오지 마세요.
연결 불가에서 접속 복구까지의 문제 해결 순서
효율적인 문제 해결의 원칙은 한 번에 하나의 변수만 바꾸는 것입니다. 노드, 프로토콜, 모드와 DNS를 동시에 바꾸면 문제가 해결되어도 진짜 원인을 알 수 없습니다. 먼저 로컬 네트워크를 확인하고, 다음으로 구독과 노드를 확인한 뒤 프로토콜 핸드셰이크를 점검하고 마지막으로 분할 라우팅과 앱별 차이를 살펴보세요.
- 프록시를 끈 상태에서 일반 웹사이트에 접속해 현재 네트워크 자체가 정상적으로 인터넷에 연결되는지 확인합니다.
- 구독을 업데이트하고 오류 메시지를 확인해 노드가 오래된 설정이나 중복 설정이 아닌지 살펴봅니다.
- 클라이언트가 명확히 지원하는 노드를 선택하고 먼저 시스템 프록시로 브라우저를 테스트합니다.
- 브라우저는 정상인데 다른 앱에 문제가 있다면 앱의 프록시 지원 여부를 확인한 뒤 TUN 사용 여부를 결정합니다.
- 규칙 모드에 문제가 있다면 일시적으로 전체 모드로 전환해 비교합니다. 전체 모드가 작동하면 규칙과 DNS를 다시 확인하세요.
- 모든 모드에서 연결할 수 없다면 로그의 해석, 연결, TLS 또는 UDP 오류를 확인하고 해당 계층에 맞춰 처리합니다.
- 복구한 뒤에는 임시 테스트 변경 사항을 되돌리고 필요한 설정만 남겨 이후 설정을 관리하기 쉽게 유지합니다.
로그의 ‘시간 초과’는 대기 시간 안에 해당 단계가 완료되지 않았다는 뜻이지만, 원인은 도메인 해석 실패, 서버 주소 접근 불가, 포트 제한이나 핸드셰이크 무응답일 수 있습니다. ‘연결 거부’는 보통 대상 주소에 도달했지만 해당 서비스가 연결을 받아들이지 않았다는 뜻입니다. ‘인증서 불일치’가 표시되면 도메인, 기기 시간과 TLS 매개변수를 확인해야 하며 일반적인 네트워크 변동으로 취급해서는 안 됩니다.