API connection via ipv6 vs. ipv4 - support - Discourse Meta 후속 질문
최근 Node.js를 18에서 20으로 업그레이드했는데, 갑자기 내 애플리케이션이 Discourse로부터 API 응답을 받지 못하게 되었습니다. 위에서 언급한 이슈와 관련이 있다는 것을 파악하는 데 시간이 좀 걸렸습니다. IPv4로만 연결하도록 설정하여 이를 확인했습니다:
import {Agent} from 'node:https'
import axios from 'axios'
import {env} from 'node:process'
export const axiosDiscourse = axios.create({
baseURL: 'https://<discourse-url>',
headers: {
'api-key': env['DISCOURSE_KEY'],
'api-username': env['DISCOURSE_USERNAME']
},
httpsAgent: new Agent({
family: 4
})
})
중요한 부분은 HTTP Agent를 지정하는 것입니다. 이전에 이 옵션 없이 사용했습니다. 이제 이렇게 하면 작동하지만, Axios를 다른 fetch 기반 라이브러리(예: Wretch)로 대체하는 것을 시도 중이었습니다. (주요 목적은 프론트엔드에서도 사용하여 번들 크기를 줄이는 것입니다): elbywan/wretch: A tiny wrapper built around fetch with an intuitive syntax.
(github.com). 그러나 fetch에서는 IPv4 또는 IPv6를 지정할 수 있는 옵션이 없습니다. 따라서 다음과 같은 두 가지 방법 중 하나를 사용해야 한다고 생각했습니다:
- 어떤 식으로든 IPv4만 사용하도록 강제하는 것. 지금까지 여러 시도를 해보았지만 성공하지 못했습니다.
- Discourse 측에 IPv6에서 이 문제를 해결하는 방법에 대해 문의하는 것.
내 애플리케이션에서는 다양한 다른 API에 연결하고 있지만, 이 문제는 Discourse 연결에서만 발생합니다.
도움이 될 경우를 대비해 발생한 오류를 공유합니다:
Error: connect ETIMEDOUT 184.105.99.43:443
at createConnectionError (node:net:1634:14)
at Timeout.internalConnectMultipleTimeout (node:net:1685:38)
at listOnTimeout (node:internal/timers:575:11)
at processTimers (node:internal/timers:514:7) {
errno: -110,
code: 'ETIMEDOUT',
syscall: 'connect',
address: '184.105.99.43',
port: 443
},
Error: connect ENETUNREACH 2602:fd3f:3:ff01::2b:443 - Local (:::0)
at internalConnectMultiple (node:net:1176:40)
at Timeout.internalConnectMultipleTimeout (node:net:1687:3)
at listOnTimeout (node:internal/timers:575:11)
at processTimers (node:internal/timers:514:7) {
errno: -101,
code: 'ENETUNREACH',
syscall: 'connect',
address: '2602:fd3f:3:ff01::2b',
port: 443
}
흥미로운 점은, 위에서 언급한 스레드와 달리 긴 시간 후에 응답이 오는 것이 아니라, 제 요청은 즉시 이 오류로 실패한다는 것입니다. 브라우저, curl, 그리고 테스트할 수 있는 다른 모든 도구에서는 API 호출이 정상적으로 작동합니다.
제 애플리케이션에서 요청을 보내는 방식은 중요하지 않습니다. 위에서 언급한 family 옵션을 사용하는 경우를 제외하고는 단순히 실패할 뿐입니다. 링크된 스레드에서 다음과 같은 언급을 볼 수 있습니다:
네트워크에서 IPv6 연결이 작동하지 않는 이유를 조사해야 합니다.
이 부분에 대해 두 가지 우려가 있습니다:
- 이를 구체적으로 어떻게 확인해야 하는지 모르겠습니다.
- 왜 이 문제가 Discourse와 제 애플리케이션에서만 발생하는지 확실하지 않습니다.
