VPN은 연결되는데 한 앱만 인터넷이 안 될 때? 그 앱의 프록시를 확인하세요

터널은 올라가 있고, 상태 페이지에는 정상적인 핸드셰이크가 표시됩니다, 그런데 한 애플리케이션만 여전히 아무것도 불러오지 못합니다. 그 애플리케이션은 아마도 더 오래된 중개자에게 요청을 계속 보내고 있을 것입니다. 시스템 프록시, 확장 프로그램, 기기 관리가 밀어 넣는 구성 파일, 또는 그 프로세스만 읽는 프록시 변수입니다. VPN 서버를 바꿔도 그 설정은 건드리지 않으며, 같은 컴퓨터에서 다른 앱이 동작하는 패턴도 이것으로 설명됩니다. 실패하는 앱에서 바깥쪽으로 조사하고, 프록시 문제가 정리될 때까지 터널은 그대로 두세요.

프록시 설정을 소유한 계층은 어디인가

앱의 요청에 권한을 주장할 수 있는 곳은 네 군데이며, 보통 가장 좁은 곳이 이깁니다. 운영체제는 전역 프록시와 선택적 자동 구성 URL을 가지고 있고, 브라우저는 이를 따르거나 덮어쓰거나 확장 프로그램에 제어를 넘길 수 있습니다. 명령줄 도구는 자체 환경을 읽고, 관리 정책은 변경 후 위의 어느 것이든 다시 고정할 수 있습니다. 무엇이든 편집하기 전에 어느 계층이 책임지는지 결정하세요. 잘못된 계층을 지우면 성공한 수정처럼 보이지만 다음 로그인에서 되돌아옵니다.

두 앱을 VPN 전용 테스트 페이지가 아니라 같은 일반 웹사이트에서 비교하세요. 브라우저는 실패하는데 터미널 다운로드는 성공한다면 운영체제가 문제가 아니며, 차이는 브라우저 프로필이나 그 확장 프로그램에 있습니다. 둘 다 실패하지만 같은 컴퓨터의 두 번째 사용자 계정에서는 성공한다면 그 설정은 사용자별입니다. 이 비교는 일 분이면 되고 대부분의 추측을 없애 줍니다.

각 도구가 실제로 사용하는 값을 읽으세요

변경하기 전에 구성을 출력하고, 정확한 프록시 문자열을 복원할 수 있는 곳에 복사해 두세요. 셸 변수는 명령줄 도구에 가장 빠른 확인 방법입니다. VPN 클라이언트는 보통 그대로 두기 때문입니다.

env | grep -i -E 'http_proxy|https_proxy|all_proxy|no_proxy'
scutil --proxy
gsettings get org.gnome.system.proxy mode
netsh winhttp show proxy

앞에 있는 플랫폼에 맞는 줄만 실행한 다음 호스트, 포트, 자격 증명에 대해 출력을 읽으세요. 다음과 같은 값은 http://proxy.corp.example:8080 도구가 모든 요청마다 그 호스트에 묻는다는 뜻이고, 빈 결과는 직접 연결한다는 뜻이며 실제 고장은 다른 곳에 있습니다. 출력을 티켓에 붙이기 전에 사용자와 비밀번호 부분을 가리세요. 그런 문자열은 사람들이 생각하는 것보다 훨씬 자주 살아 있는 자격 증명입니다.

자체 프록시 엔진을 가진 도구는 자체 증거가 필요합니다. Curl은 자세한 정도를 높이면 내린 결정을 알려 주며, 이는 환경에서 추측하는 것보다 낫고, 같은 플래그로 이름 해석이 로컬에서 일어났는지 프록시에서 일어났는지도 보여 줍니다.

재정의를 지우고 같은 요청을 다시 테스트하세요

한 계층을 바꾼 다음 실패한 바로 그 요청을 반복하세요. 다른 URL은 아무것도 증명하지 못합니다. 먼저 현재 셸의 환경 변수를 지우세요. 그 편집은 되돌릴 수 있고 터널을 끊을 수도 없습니다:

unset http_proxy https_proxy all_proxy
curl -v --max-time 10 https://example.com 2>&1 | grep -i -E 'uses proxy|connected to|http/'

자세한 출력이 여전히 프록시를 주장한다면 환경이 권한이 아니었습니다. 재정의를 더 쌓는 대신 한 단계 위로 올라가세요.

macOS에서는 자동 구성 파일이 값을 제공하지 않는지 확인한 다음 서비스 프록시를 끄고 변경을 확인하세요. Windows에서는 WinHTTP 설정과 사용자별 브라우저 설정이 서로 다른 객체라는 점을 기억하세요. 그래서 깨끗한 명령줄 도구가 여전히 오래된 서버를 가리키는 브라우저와 공존할 수 있습니다. 확장 프로그램도 같은 의심을 받을 만합니다. 프록시 확장 프로그램은 한 프로필에만 요청을 다시 쓸 수 있으며, 이는 브라우저 하나에만 영향을 주고 다른 것에는 영향이 없는 고장의 정확한 형태입니다.

수정이 재시작 후에도 유지되는지 확인하세요

편집한 터미널에서만 동작하는 설정은 수정된 것이 아닙니다. 데스크톱 실행기에서 앱을 다시 열고, 로그아웃했다가 다시 로그인하고, 예전 프록시가 돌아오는지 보세요.

두 가지 확인이 진짜 수정과 임시 수정을 구분하며, 둘 다 직접 연결 또는 의도한 값을 보고해야 합니다. 깨끗한 환경에서 실행하면 정리된 프로세스가 여전히 시스템 설정을 가져오는지 보여 줍니다.

env -i /usr/bin/curl -sS -o /dev/null -w '%{http_code} %{remote_ip}
' https://example.com
networksetup -getwebproxy "Wi-Fi"

재시작 후 예전 값이 돌아온다면 출처는 그것을 다시 적용하는 관리 정책이나 프로필이며, 그 정책의 소유자가 예외를 제거해야 합니다. 인증서 검증은 계속 켜 두세요. 트래픽을 가로채는 프록시는 검사를 끄는 순간 해결된 것처럼 보이기 때문입니다. 마지막으로 제거한 값과 날짜를 메모에 적어 두세요. 다음 사람이 의도한 프록시와 잊힌 프록시를 구분할 수 있도록 하기 위해서입니다.