프로그래밍/네트워크

[트러블 슈팅] Wi-Fi에서 특정 사이트만 접속되지 않는 문제를 네트워크 계층별로 추적한 기록 (AdGuard 광고차단기 인터넷 접속 문제)

d 0_0 b 2026. 7. 11. 15:01

 

최근 맥북에서 이상한 네트워크 문제가 발생했습니다. 핫스팟으로 연결하면 인터넷이 정상적으로 되었지만, Wi-Fi에 연결하면 일부 사이트가 열리지 않았습니다.

 

 

처음에는 Wi-Fi 자체가 문제라고 생각했습니다. 하지만 확인해보니 Notion 같은 서비스는 Wi-Fi에서도 접속되었습니다. 반면 자소설닷컴, ChatGPT, GPT 응답과 관련된 서비스는 Wi-Fi에서 접속되지 않았고, 핫스팟에서는 정상적으로 접속되었습니다.

문제를 해결하는 과정에서 단순히 “인터넷이 안 된다”가 아니라, 컴퓨터 네트워크 관점에서 어떤 계층에서 문제가 발생하는지 나누어 확인했습니다.

1. 문제 범위 정의

처음 증상은 다음과 같았습니다.

  • 핫스팟에서는 정상 접속
  • Wi-Fi에서는 일부 사이트 접속 실패
  • Notion은 Wi-Fi에서도 접속 가능
  • 자소설닷컴, ChatGPT 등은 Wi-Fi에서 접속 실패
  • Chrome에서는 ERR_ADDRESS_INVALID가 표시됨

이 시점에서 문제를 다음과 같이 좁힐 수 있었습니다.

Wi-Fi 물리 연결 자체가 끊어진 것은 아니었습니다. 일부 서비스는 정상 접속되었기 때문입니다. 따라서 L1, L2 수준의 단순 연결 문제보다는 DNS, 라우팅, TCP 연결, HTTP 계층, 혹은 로컬 네트워크 필터 문제를 의심해야 했습니다.

2. 비교군 설정

네트워크 문제를 볼 때 중요한 것은 비교군입니다. 같은 장비에서 네트워크만 바꾸어 비교했습니다.

  • Wi-Fi
  • 핫스팟

또한 같은 네트워크에서 접속 대상을 바꾸어 비교했습니다.

  • Notion
  • Google
  • Naver
  • 자소설닷컴
  • ChatGPT
  • OpenAI API

그리고 같은 도메인에 대해 브라우저와 터미널을 비교했습니다.

  • Chrome 접속
  • curl 접속
  • dig DNS 조회

이렇게 비교하면 문제를 막연하게 보지 않고, 어떤 조건에서만 실패하는지 확인할 수 있습니다.

3. DNS 계층 확인

먼저 DNS가 정상적으로 동작하는지 확인했습니다.

dig jasoseol.com A
dig jasoseol.com AAAA
dig chatgpt.com A
dig api.openai.com A

자소설닷컴과 OpenAI 관련 도메인은 정상적으로 IP 주소를 반환했습니다.

예를 들어 자소설닷컴은 Cloudflare IP로 해석되었습니다.

jasoseol.com. A 162.159.140.141
jasoseol.com. A 172.66.0.139

DNS 응답이 정상이라는 것은, 적어도 도메인 이름을 IP 주소로 바꾸는 과정 자체가 완전히 실패한 것은 아니라는 뜻입니다.

따라서 문제를 “DNS가 안 된다”로 단정할 수 없었습니다.

4. 전송 계층과 애플리케이션 계층 확인

다음으로 실제 HTTPS 연결이 가능한지 확인했습니다.

curl -I 'https://jasoseol.com/recruit?ec=[NNNNN]'
curl -I https://chatgpt.com
curl -I https://api.openai.com/v1/models

터미널에서는 자소설닷컴이 HTTP/2 200을 반환했습니다.

HTTP/2 200
server: cloudflare

OpenAI API는 HTTP/2 401을 반환했습니다.

HTTP/2 401
www-authenticate: Bearer realm="OpenAI API"

여기서 401은 네트워크 실패가 아닙니다. 인증 정보 없이 API에 접근했기 때문에 거절된 것입니다. 즉, TCP 연결과 TLS, HTTP 요청은 서버까지 도달했습니다.

이 결과로 시스템 전체 네트워크가 완전히 막힌 상태는 아니라는 것을 확인했습니다.

 

5. 브라우저와 시스템 네트워크의 차이

흥미로운 점은 터미널에서는 접속이 되는데, Chrome에서는 특정 사이트가 열리지 않았다는 것입니다.

 

이 차이는 중요합니다.

브라우저에서 사이트가 열리지 않는다고 해서 항상 네트워크 계층이 실패한 것은 아닙니다. Chrome 내부에는 DNS 캐시, 소켓 풀, 보안 DNS 설정, 확장 프로그램, 사이트별 캐시가 존재합니다. 또한 macOS에는 브라우저보다 더 낮은 위치에서 동작하는 네트워크 확장도 있습니다.

 

Chrome에서 ERR_ADDRESS_INVALID가 나왔지만, 터미널에서 curl이 성공한다면 다음을 의심할 수 있습니다.

  • Chrome DNS 캐시
  • Chrome Secure DNS 설정
  • 브라우저 확장 프로그램
  • OS 레벨 네트워크 필터
  • 특정 도메인에 대한 로컬 필터링

 

6. macOS Network Extension 확인

macOS에서 네트워크 트래픽을 가로채는 확장이 있는지 확인했습니다.

systemextensionsctl list

결과는 다음과 같았습니다.

* * TC3Q7MAJXF com.adguard.mac.adguard.network-extension
AdGuard Network Extension [activated enabled]

AdGuard Network Extension이 활성화되어 있었습니다.

AdGuard는 악성 광고를 차단하기 위한 확장프로그램으로 일전에 다운로드 후에 사용하고 있었습니다.

 

여기서 중요한 점은 AdGuard가 단순한 브라우저 확장이 아니라는 것입니다. macOS Network Extension은 OS 네트워크 스택에 가까운 위치에서 트래픽을 필터링할 수 있습니다. 따라서 Chrome 확장을 꺼도 시스템 확장이 살아 있으면 네트워크 트래픽에 계속 개입할 수 있습니다.

 

AdGuard 앱에서 보호 기능을 껐다고 해서 macOS Network Extension이 반드시 꺼지는 것은 아니었습니다. 실제로 시스템에서는 여전히 activated enabled 상태였습니다.

 

 

7. 네트워크 계층 관점에서 정리

이번 문제를 OSI 계층 관점으로 정리하면 다음과 같습니다.

L1, L2 수준의 문제는 아니었습니다. Wi-Fi 연결 자체는 유지되었고, 일부 서비스는 정상 접속되었습니다.

L3 수준에서는 IP 주소와 라우팅을 확인했습니다. 핫스팟에서는 192.0.0.2, CLAT46, NAT64 형태가 보였습니다. 이는 일반적인 가정용 공유기 DHCP 환경과 다르게 이동통신망에서 나타날 수 있는 형태입니다. 이 결과만으로 Wi-Fi 문제를 판단하면 안 되었습니다.

L4 수준에서는 TCP 연결 가능 여부를 봐야 했습니다. 단순히 ping이 된다고 HTTPS가 된다고 볼 수 없기 때문입니다.

L7 수준에서는 HTTP 응답 코드를 확인했습니다. 200, 401, 403은 모두 의미가 다릅니다. 특히 401은 네트워크 실패가 아니라 인증 실패입니다.

마지막으로 OS 정책 계층을 확인했습니다. 실제 원인 후보는 AdGuard Network Extension처럼 애플리케이션과 커널 네트워크 스택 사이에 개입하는 필터였습니다.

 

 

8. 이 문제에서 얻은 트러블슈팅 원칙

이번 문제에서 가장 중요했던 것은 증상을 바로 원인으로 연결하지 않는 것이었습니다.

“Wi-Fi가 안 된다”는 표현은 너무 넓습니다. 실제로는 Wi-Fi에서 모든 사이트가 안 되는 것이 아니라, 특정 사이트만 실패했습니다. 다시 확인해보니 Notion은 되었고, 자소설닷컴과 GPT 관련 서비스가 실패했습니다.

따라서 문제를 다음 순서로 줄여갔습니다.

인터넷 전체 장애인가
→ 특정 네트워크에서만 발생하는가
→ 특정 사이트에서만 발생하는가
→ DNS는 정상인가
→ TCP/HTTPS 연결은 정상인가
→ 브라우저만 실패하는가
→ OS 레벨 필터가 개입하는가

이 방식은 네트워크 트러블슈팅에서 중요합니다. 한 번에 정답을 찾으려고 하기보다, 가능한 원인을 하나씩 제거하는 방식이라는 것을 알게 되었습니다.

 

 

9. 결론

이번 문제의 핵심 원인 후보는 AdGuard Network Extension이었습니다.

브라우저 확장이나 앱 화면의 보호 상태가 아니라, macOS 시스템 확장 상태를 확인해야 했습니다.

systemextensionsctl list

여기서 AdGuard가 다음처럼 표시되면 아직 네트워크에 개입 중입니다.

AdGuard Network Extension [activated enabled]

따라서 해결은 AdGuard 앱에서 단순히 보호 기능을 끄는 것이 아니라, macOS 설정에서 Network Extension을 비활성화하거나 AdGuard를 완전히 제거한 뒤 재부팅하는 것입니다.

 

결과는 성공적이었고, 이젠 wifi로도 정상적인 접근이 가능해졌습니다.

 

이번 문제는 네트워크 장애를 볼 때 물리 연결, DNS, 라우팅, TCP, HTTP, 브라우저, OS 네트워크 확장을 분리해서 확인해야 한다는 점을 보여준 사례였습니다.

'프로그래밍 > 네트워크' 카테고리의 다른 글

[네트워크] network layer - Data Plane(Router) 1  (0) 2023.11.18
네트워크 (8) - 웹 캐싱(Web caching,proxy server)  (0) 2023.11.11
네트워크(7) - 쿠키 ( Cookie )  (0) 2023.10.15
네트워크(6) - Web and HTTP  (0) 2023.10.09
네트워크(5) - 인터넷 전송 프로토콜이 제공하는 서비스(TCP, UDP)  (0) 2023.10.09

'프로그래밍/네트워크'의 다른글

  • 현재글[트러블 슈팅] Wi-Fi에서 특정 사이트만 접속되지 않는 문제를 네트워크 계층별로 추적한 기록 (AdGuard 광고차단기 인터넷 접속 문제)

관련글

티스토리툴바