호텔 네트워크가 연결되지 않는 이유
호텔 Wi-Fi 문제는 대부분 클라이언트가 아니라 입구에 있습니다. 아래 몇 가지 원인이 거의 모든 상황을 덮으므로, 빈도 순으로 위에서부터 확인하면 됩니다.
캡티브 포털 인증 미완료
Wi-Fi에 연결한 뒤 브라우저에서 객실 번호나 인증 코드를 입력해야 하고, 인증이 끝나기 전까지 게이트웨이는 포털 페이지만 허용하고 나머지 트래픽은 모두 차단합니다. 이 상태에서 클라이언트를 먼저 켜면 핸드셰이크 패킷이 그대로 버려져 계속 로딩만 돌거나 시간 초과가 뜹니다. 순서는 브라우저로 인증을 마친 뒤 회선에 연결하는 것이고, 프록시 상태에서 포털 페이지가 열리지 않으면 프록시를 먼저 끄고 다시 시도하세요.
포트와 프로토콜 제한
일부 호텔은 80과 443만 허용하고 UDP는 속도를 제한하거나 아예 버립니다. UDP 기반 프로토콜은 이런 네트워크에서 핸드셰이크가 실패하며, Hysteria2와 TUIC도 QUIC 위에서 동작하므로 마찬가지입니다. 표준 HTTPS로 위장하는 TCP 443 프로토콜(Trojan, VLESS)이 연결을 맺기 쉽습니다. 출장 전에 TCP 443 설정을 하나 준비해 두는 것이 가장 간단합니다.
DNS 가로채기와 이중 NAT
호텔 게이트웨이는 DNS를 자기 쪽으로 돌리는 경우가 많아 조회 결과가 로컬과 어긋나고, 웹페이지는 열리는데 클라이언트는 붙지 않는 현상이 생깁니다. 이중 NAT는 역방향 연결이 필요한 기능을 무력화합니다. DNS 조회를 터널로 보내고 DNS 유출 자가 점검을 한 번 하면 이런 문제의 상당 부분을 걸러낼 수 있습니다.
객실 유선 포트와 AP 격리
일부 호텔은 객실 유선 포트와 Wi-Fi가 서로 다른 대역이라 기기 간에 보이지 않습니다. 같은 노트북을 Wi-Fi에서 유선으로 옮기면 분할 라우팅의 로컬 대역 판정이 어긋나 네트워크를 바꾸는 순간 끊기기도 합니다. 이럴 때는 로컬 대역 설정을 다시 확인하면 대개 복구됩니다.
인증 먼저, 연결은 그다음
호텔 네트워크에서 가장 흔한 실수는 순서를 뒤집는 것입니다. 클라이언트를 먼저 켜고 포털 인증을 하러 가는 경우죠. 포털 페이지는 프록시 아래에서 열리지 않는 일이 많아 인증 자체가 끝나지 않습니다. 두 단계를 바꾸면 연결 실패의 대부분이 사라집니다.
출장에 필요한 트래픽: 일정 길이별 비교
트래픽 요구량은 세 가지로 결정됩니다. 일정 길이, 하루 접속 시간, 화상회의 여부입니다. 시간당 소모량을 외우기보다 구간표로 비교하면 구매 전에 충분한지 알 수 있습니다.
| 일정과 사용 방식 | 권장 구간 | 설명 |
|---|---|---|
| 3–5일, 메일·문서·메신저 중심 | 월 구독 ¥9.9 / 60GB | 단기 출장에서 가장 흔한 조합, 트래픽은 개통일 기준 매월 초기화 |
| 1–2주, 매일 화상회의와 클라우드 문서 | 월 구독 ¥18 / 250GB | 회의와 동기화 폴더를 동시에 켜도 여유 있음 |
| 장기 주재, 대용량 파일 전송과 원격 데스크톱 | 월 구독 ¥28 / 500GB | 단일 구간 최대, 회선을 일상 네트워크처럼 쓰는 용도 |
| 1년에 출장이 몇 번뿐 | 트래픽 패키지 ¥158 / 300GB부터 | 다 쓸 때까지 유효, 기간 만료 없음, 매월 갱신 불필요 |
월 구독 트래픽은 개통일 기준으로 매월 초기화되고, 중간에 상위 구간으로 올리면 차액이 남은 일수로 환산됩니다. 트래픽 패키지는 다 쓸 때까지 유효하고 기간이 만료되지 않아, 사용량이 출장 주간에 몰리는 사람에게 맞습니다. 기기 수 제한은 없어 스마트폰·노트북·태블릿을 동시에 로그인할 수 있고, 두 번째 기기 때문에 따로 결제할 필요가 없습니다.
구매 전에 클라이언트의 트래픽 통계를 보세요. 대표적인 출장일 하루 사용량을 기록해 일정 일수로 곱하면 감으로 어림하는 것보다 정확합니다. 동기화 폴더, 시스템 업데이트, 사진 백업 같은 백그라운드 트래픽이 가장 쉽게 간과되니, 출발 전에 Wi-Fi 전용이나 수동 동기화로 바꿔 두세요.
단기 출장은 최소 구간으로 시작: ¥9.9에 60GB면 3–5일의 메일·문서·웹 사용을 덮습니다. 일정이 2주를 넘고 매일 화상회의를 해야 한다면 ¥18에 250GB 구간으로 옮기는 편이 예산과 여유 모두 안정적입니다.
해외 업무 앱은 제대로 쓸 수 있을까
제대로 쓸 수 있는지는 그 앱이 무엇에 민감한지에 달려 있습니다. 네 가지로 나눠 보면 '연결되나요'라고 뭉뚱그려 묻는 것보다 훨씬 유용합니다.
메일, 캘린더, 문서
443, 993, 465 같은 고정 포트를 쓰므로 회선 요구 조건이 가장 낮습니다. 진짜 함정은 DNS입니다. 잘못된 엣지 노드로 조회되면 첨부 파일 다운로드 속도가 들쭉날쭉해집니다. DNS를 터널로 보내면 이런 문제는 거의 사라집니다.
화상회의
패킷 손실과 지터에 가장 민감합니다. 회의 앱은 대개 UDP를 우선하는데, 호텔 네트워크가 UDP를 제한하면 화면이 자동으로 저해상도로 떨어지고 심하면 연결이 끊깁니다. 출장 중에는 클라이언트를 바꾸는 것보다 회의를 IEPL 전용 회선이나 저지연 중계 회선에 태우는 편이 효과적입니다.
코드 저장소와 패키지 관리자
저장소 클론, 이미지 풀, 의존성 설치 모두 긴 연결과 큰 트래픽을 쓰므로 중간에 끊기는 것이 문제입니다. 이어받기를 지원하는 도구는 계속 받을 수 있지만, 지원하지 않으면 처음부터 다시 해야 합니다. 출발 전에 자주 쓰는 미러를 설정해 두면 대기 시간을 절반으로 줄일 수 있습니다.
사내 시스템, SSH, 원격 데스크톱
이런 연결에 필요한 것은 대역폭이 아니라 안정성입니다. 회사 내부 대역을 직접 연결 분할 규칙에 넣으면 우회 경로를 피할 수 있고, 사내 도메인이 프록시에서 외부 주소로 해석되는 것도 막을 수 있습니다.
| 앱 종류 | 주요 민감 요소 | 회선 권장 |
|---|---|---|
| 메일 / 캘린더 / 문서 | DNS 조회, 고정 포트 | 직접 연결 또는 중계 |
| 화상회의 | 패킷 손실, 지터, UDP 가용성 | IEPL 전용 회선 |
| 코드 저장소 / 패키지 관리자 | 긴 연결, 처리량 | 중계 또는 전용 회선 |
| SSH / 원격 데스크톱 / 데이터베이스 | 연결 안정성 | IEPL 전용 회선 |
브라우저 탭, 동기화 폴더, 시스템 업데이트는 백그라운드에서 계속 트래픽과 연결 수를 잡아먹습니다. 회의 시작 전에 이들을 잠시 멈추는 편이 나중에 요금제를 올리는 것보다 효과적입니다.
경험을 좌우하는 것은 회선 유형이지 클라이언트 개수가 아닙니다. 회의와 원격 데스크톱은 전용 회선에, 저장소와 문서는 중계로 충분합니다. 모든 트래픽을 한 회선에 몰아넣는 것이 출장 중 가장 흔한 성능 낭비입니다.
출발 전 체크리스트
아래 목록은 출발 전과 체크인 후 두 구간으로 나눴습니다. 그대로 따라 하면 현장에서 생기는 대부분의 문제를 피할 수 있습니다.
- ✅ 출발 전에 노트북에 클라이언트를 설치하고 로그인까지 마쳐 두세요. 호텔 방에서 내려받지 마세요.
- ✅ 구독을 가져온 뒤 노드 목록을 한 번 수동으로 새로 고쳐 회선이 보이는지 확인하세요.
- ✅ 클라이언트에 TCP 443 예비 설정을 하나 준비하세요.
- ✅ DNS를 터널로 보내도록 켜고 DNS 유출 자가 점검을 한 번 하세요.
- ✅ 회사 내부 대역, NAS, 프린터를 직접 연결 분할 규칙에 넣으세요.
- ✅ 스마트폰에도 구독 정보를 남겨 두면 기기를 바꿀 때 빠르게 복구할 수 있습니다.
- ❌ 호텔 포털 인증을 마치기 전에 클라이언트를 켜지 마세요.
- ❌ 전역 모드를 기본으로 두지 마세요. 로컬 은행과 포털 페이지가 열리지 않습니다.
- ❌ 공용 PC에서 계정 패널에 로그인하지 마세요.
회선과 프로토콜 선택
회선 유형은 안정성을, 프로토콜은 연결 가능 여부를 결정합니다. 두 가지를 나눠 보면 선택이 훨씬 명확해집니다.
세 가지 회선 유형
- IEPL 전용 회선: 경로가 고정되고 공용 인터넷 출구를 거치지 않아 피크 시간에도 변동이 적습니다. 비용이 가장 높고 화상회의와 원격 데스크톱에 적합합니다.
- 중계: 입구와 착지 지점 사이를 최적화된 경로로 지나가며 가격과 안정성이 중간 수준이라 일상 기본값으로 적합합니다.
- 직접 연결: 착지 노드에 바로 연결하므로 공용 인터넷 상황에 따라 품질이 달라집니다. 실시간성이 중요하지 않은 다운로드와 웹 브라우징에 적합합니다.
프로토콜 고르는 법
Shadowsocks는 가볍고 오버헤드가 작습니다. VMess는 사용자 식별자를 포함하고 다중화를 지원합니다. Trojan은 표준 HTTPS 트래픽으로 위장해 443만 허용하는 네트워크에서 통과하기 쉽습니다. VLESS는 더 간결하며 TLS 계열 위장과 자주 조합됩니다. Hysteria2와 TUIC는 QUIC 기반이라 손실이 많은 네트워크에서 재전송이 더 적극적이지만, UDP를 막는 네트워크에서는 아예 쓸 수 없습니다. 출장 중 권장 순서는 TCP 443 설정으로 연결을 먼저 확인하고, 네트워크 품질에 따라 UDP 계열로 바꿀지 결정하는 것입니다.
분할 라우팅 규칙 작성법
기본 순서는 이렇습니다. 회사 내부와 로컬 대역은 직접 연결, 현지에서 자주 쓰는 서비스는 직접 연결, 나머지는 프록시. 전역 모드는 간편해 보이지만 호텔 포털, 로컬 은행, 지도 서비스까지 우회하게 되어 오히려 문제가 생기기 쉽습니다. 규칙을 만든 뒤 출발 전에 한 번 실행해 사내 도메인이 내부 주소로 해석되는지 확인하세요.
VPNCQ의 회선은 120+ 국가 / 150+ 회선을 커버하며, 기기 수 제한 없이 첫 결제 후 30일 이내에 이유 없는 환불을 신청할 수 있습니다. 가입에는 사용자 이름과 비밀번호만 필요하고 이메일 주소는 요구하지 않습니다. 결제는 알리페이, 위챗, USDT를 지원합니다. 회선 암호화는 전 구간 양자 암호화 방식을 적용합니다.
자주 묻는 질문 빠른 답변
호텔 네트워크가 연결되지 않을 때 첫 단계는?
클라이언트를 먼저 끄고 브라우저로 아무 http 페이지나 열어 포털 인증을 띄운 뒤, 인증을 마치고 회선에 연결하세요. 그래도 실패하면 TCP 443 예비 설정으로 바꾸세요.
일주일 출장이면 트래픽 패키지와 월 구독 중 무엇이 나을까요?
사용량이 출장 기간에 몰리는지로 판단하세요. 1년에 몇 번만 출장한다면 다 쓸 때까지 유효하고 만료되지 않는 트래픽 패키지가 낫고, 매달 출장이 있다면 월 구독이 더 저렴합니다.
트래픽 패키지를 다 쓰지 못하면 소멸하나요?
아니요. 트래픽 패키지는 다 쓸 때까지 유효하고 기간이 만료되지 않습니다. 그래서 출장 빈도가 낮은 사람에게 맞습니다.
회의 화면이 끊기는 건 대역폭이 부족해서인가요?
대부분은 대역폭이 아니라 패킷 손실과 지터 때문입니다. 요금제를 올리는 것보다 IEPL 전용 회선이나 저지연 중계 회선으로 바꾸는 편이 직접적입니다.
회사 내부 시스템에 접속할 수 없으면 어떻게 하나요?
먼저 사내 대역을 직접 연결 분할 규칙에 추가하고, DNS가 프록시에 넘어가지 않았는지 확인하세요. 일부 사내 시스템은 특정 출구만 허용하므로 운영 담당자와 정책을 확인해야 합니다.
출장 VPN 선택은 세 단계로 줄일 수 있습니다. 먼저 TCP 443 설정으로 연결 가능 여부를 해결하고, 다음으로 일정 길이에 맞춰 트래픽 구간을 골라 충분한지를 해결하고, 마지막으로 앱 종류에 따라 회선을 배분해 안정성을 해결합니다. 이 세 단계 밖에서는 출발 전 체크리스트가 어떤 스펙보다 유용합니다.