통신사 테더링 후 Node.js 프로그램 내 Request 안되는 이슈 (1/2)

1. 배경 

개발한 Node.js 기반 Electron Framework로 만든 클라이언트 프로그램은 실행 시, axios를 통해 특정 서버 상태를 확인하는 로직이 들어가 있다. 

Get방식의 특정 URL 을 호출해 리턴되는 Response 내 status를 확인하고 큰 이상 없으면 넘어가는 아주 단순한 로직이다. 

이게 정상적으로 처리되지 않으면 에러대응 페이지로 넘겨주도록 되어있다. 

---

어느날 클라이언트 내에서 에러대응 페이지가 계속 나온다는 이슈보고가 들어왔다.

침착하게 확인해본 결과... 아무 이상이 없었다. 

팀 동료들에게 테스트를 부탁하였는데 다들 아무도 이상이 없었다고 한다.

즉, 정상적으로 실행되고 있었다. 

처음엔 서버가 다운된거 아닐까 하는 의심을 받았지만, 서버는 아무 이상이 없었다. 

도대체 뭐가 문제일까?

이슈 보고자분께 브라우저에서 URL을 직접 타이핑하여 접속유무를 확인했다. 혹여나 해당 PC에서만 접속이 안 되는 걸수도 있으니까...

확인결과 브라우저에서는 정상 작동하였다. 즉, 서버도 이상없고 접속하는 환경도 크게 이상은 없다는 것이다.

이슈 보고자분께 따로 환경을 여쭤본 결과, 차이점은 딱 하나. 테더링이었다. 

 

동일 환경 테스트를 진행해 보기로 했다. 

설마 하는 마음에 팀원들 모두 테더링을 활성화한 후, 테스트를 진행하자 특이점이 발견되었다.

통신사	PC	기종	결과
L 통신사	MacBook Pro (arm)	아이폰 13 미니	정상 접속
L 알뜰 통신사	MacBook Pro (arm)	아이폰 13	정상 접속
S 통신사	MacMini  (arm)	아이폰 13 프로	접속 불가
S 알뜰 통신사	MacBook Pro (arm)	아이폰 13	접속 불가

아이폰 13 계열이지만, 이건 통신사 쪽 관련일 가능성이 높지 않을까?라는 생각이 들었다.

단순히 접속되고 안되고를 떠나서 명확하게 StatusCode를 확인해보고 싶어 아래와 같이 테스트를 진행했다.

 

2. 테스트 

클라이언트

• Node.js v18.16.0 
• Mac mini m1 
• SKT 테더링 wifi  
• https으로 요청

서버

• Cent OS 7 
• Nginx ( reverse Proxy )  
• React 18 기반 클라이언트 사이드 렌더 HTML 페이지
• VPN으로만 접속 가능한 환경

VPN Client

• FortiClient

 테스트 코드 

// test.js 

const https = require("https");

const url = "{URL 주소}";

const request = https.get(url, { timeout: 2000 }, (response) => {
    const { statusCode } = response;

    if (statusCode === 200) {
      console.log("통과");
    } else {
      console.log("안됨");
      console.error(`에러 상태 코드: ${statusCode}`);
    }
  })
  .on("error", (error) => {
    console.error("요청 중 에러 발생:", error.message);
  });

// 타임아웃 설정
request.setTimeout(2000, () => {
  console.error("요청 시간 초과");
  request.abort(); // 요청 취소
});

실행

node test.js

 

3. 테스트  결과    

 

연결 WIFI	결과
S통신사 요금제( 아이폰13 ) 테더링 Wifi
SKB Giga lite + Asus 공유기 Wifi

요청시간 초과의 경우 아예 도메인을 바라보지 못했는지 nginx 로그에도 아무런 로그기록이 발생하지 않음

 

4. 원인 

SKB Giga lite + Asus 공유기 Wifi 환경에서와 S통신사 요금제 + 아이폰 13 Pro 테더링 Wifi 환경에서의 차이를 확인하기 위해 wireshark로 확인해 본 결과 요청 시 Source와 Destination 이 IPv4로 요청하냐, IPv6로 요청하냐의 차이가 발생함을 확인했다. 

이로 인해 도메인을 찾지 못해 결국 요청이 의미 없어져 사실상 테스트결과와 같이 요청시간 초과 관련 에러를 뱉는 게 정상임을 확인했다. 

L 통신사를 사용하는 경우에는 IPv4로 가는지는 확인하지 않았지만, 아마 그럴 것이다. 정상적으로 통신되기 때문에.. 

이슈 보고자의 말에 따르면 기존엔 잘 되었었다고 하니 아마 과거에는 IPv4방식으로 요청하였을 텐데, 변경된 게 아닌가 하는 생각이 든다.

 

5. 해결 방안 

원인이 파악되었으므로 해결방안은 총 3가지로 도출할 수 있었다. 

1. 클라이언트 프로그램 실행이 되는  PC / 모바일 내 IPv6를 비활성화 처리  
2. Node.js  내 http/https Request 시 axios , request.js 내 IPv4 고정 요청 처리
3. 도메인 내 AAAA 레코드 추가 / Nginx Server Conf 파일 내 IPv6 호환 설정 

 

6. 결론

이건 절대적으로 S사의 문제가 아니다. 되려 IPv6를 제대로 대응하지 못한 서버관리자의 책임이 크다. 

오히려 통신사는 이미 나온진 꽤 되었지만 나름 최신 표준을 사용한 것 뿐이고, IPv6 방식의 아이피 구조를 아예 고려조차 하지 못한 내 잘못인 것이다.  

추후에 웹 관련 서버 구현시에는 꼭 이 점에 대해 잊지 말아야겠다. 

 

 

해결방안을 적용하는 방법에 대해서는 다음 게시글에서 확인할 수 있다.