curl 오류 6과 오류 7의 차이는 무엇인가요?

실패하는 단계가 다르고, 이 구분이 문제를 좁히는 가장 빠른 길입니다. 오류 6 — 'Could not resolve host'(CURLE_COULDNT_RESOLVE_HOST) — 는 이름 해석 중에, curl이 접속할 IP 주소를 얻기도 전에 발생합니다. 아직 서버로 가는 네트워크 경로를 건드리지도 않았으니, 방화벽·닫힌 포트·서버 다운 문제일 리가 없습니다. 오류 7 — 'Failed to connect'(CURLE_COULDNT_CONNECT) — 는 해석이 성공한 뒤에 일어납니다. curl이 IP를 얻어 그 IP로 TCP 접속을 시도했는데 거부당하거나 닿지 못한 거죠. 그러니 6이 보이면 DNS와 프록시 설정을 보고, 7이 보이면 이름은 잘 해석됐으니 포트·방화벽·서비스 가동 여부를 보세요.

nslookup·dig로는 이름이 잘 나오는데 curl만 (6)이라고 합니다. 왜죠?

이건 문제가 DNS가 아니라 프록시 환경변수라는 전형적인 신호입니다. curl은 환경에서 http_proxy, https_proxy, no_proxy(그리고 대문자 형태)를 읽습니다. dig와 nslookup은 안 읽어요. https_proxy가 해석 안 되는 프록시 호스트를 가리키거나 프록시가 죽었으면, curl은 해석 단계에서 실패하는데 — 못 푸는 이름은 당신의 타깃이 아니라 프록시의 이름입니다. 'env | grep -i proxy'로 뭐가 설정됐는지 보세요. 셸 프로파일이나 컨테이너 환경에 남은 낡은 프록시 변수가, 멀쩡히 되는 dig 옆에서 말 안 되는 (6)을 내는 가장 흔한 원인 중 하나입니다.

브라우저에서는 되는 호스트명을 curl은 왜 해석하지 못하나요?

대개 브라우저와 curl이 서로 다른 경로로 해석하기 때문입니다. 그 이름이 내부·VPN 전용 호스트명이라, 브라우저는 시스템 프록시나 VPN DNS로 닿는데 커맨드라인 curl은 그걸 안 쓰는 경우가 많아요. 또는 브라우저가 자체 DNS 캐시나 보안 DNS(DoH)를 쓰는데, curl은 그걸 무시하고 /etc/resolv.conf의 시스템 리졸버를 쓰기도 합니다. 그 이름이 애초에 공개용인지, 지금 curl이 기대하는 VPN에 붙어 있는지, /etc/resolv.conf가 실제로 무엇을 가리키는지 확인하세요.

curl: (6) Could not resolve host 해결

이 오류가 알려주는 것

curl: (6) Could not resolve host는 DNS 실패이고, 그걸 아는 순간 아무것도 건드리기 전에 인터넷의 절반이 용의선상에서 빠집니다. curl은 호스트명을 IP 주소로 바꾸려는 데까지만 갔고 못 했습니다. 접속을 연 적도, 서버로 한 바이트도 보낸 적도, 포트를 확인한 적도 없어요. 그러니 당신이 탓하고 싶은 것 — 방화벽, 원격 서버 다운, 잘못된 인증서 — 은 아직 아무것도 관여하지 않았습니다. 이름이 해석 안 됐고, 그건 회선의 당신 쪽, 해석 단계의 문제입니다.

이건 사실 좋은 소식입니다. 원인이 짧고 확인 가능한 목록이라는 뜻이니까요. 내부 오류 코드는 CURLE_COULDNT_RESOLVE_HOST이고, 이게 터지는 이유는 정말 세 부류뿐입니다.

오타부터 지운다

시시하지만 자주 정답입니다. 글자가 뒤바뀐 호스트명, 끼어든 공백, 붙여넣다 딸려온 폭 없는 문자(zero-width), htttp://로 망가진 파싱 — 전부 (6)을 냅니다. 오류에 찍힌 정확한 이름을 당신이 치려던 것과 대조해 읽으세요. 스크립트로 URL을 만든다면 curl 호출 직전에 그걸 echo해 보세요 — 빈 값으로 확장된 변수는 https://$HOST/api를 https:///api로 만들고, curl은 빈 호스트도 해석하지 못합니다.

“내 리졸버가 고장” vs “curl만 특이함” 가르기

이름이 맞아 보이면, 가장 유용한 한 수는 curl 없이 그 이름을 해석해 보는 겁니다.

getent hosts example.com     # 또는: dig example.com  /  nslookup example.com

이렇게 하면 문제가 깔끔하게 둘로 갈립니다.

여기서도 이름이 해석 안 된다. 그럼 시스템 리졸버나 DNS 자체 문제입니다. /etc/resolv.conf가 작동하는 네임서버를 가리키는지, 그 이름이 유효한 네트워크·VPN에 붙어 있는지, 도메인이 실제로 존재하고 만료되거나 레코드를 잃지 않았는지 확인하세요. 컨테이너가 단골 범인입니다 — 최소 이미지는 리졸버가 아예 설정 안 됐거나, 닿지 못하는 네임서버를 물려받기도 합니다.
dig/getent로는 잘 되는데 curl만 (6)이다. 그럼 DNS는 멀쩡하고 curl에 특이한 무언가가 끼어 있는 겁니다. 단골 범인은 프록시 환경변수(FAQ 참고)예요 — curl은 http_proxy/https_proxy/no_proxy를 존중하는데 다른 도구는 안 그럽니다. 그보다 드물게는, 작동하는 리졸버 백엔드 없이 빌드된 curl이거나, 잊고 있던 --resolve/--connect-to 오버라이드입니다.

프록시 함정

이건 따로 짚을 값어치가 있습니다. 시간을 너무 많이 잡아먹거든요. https_proxy가 오타 나거나 폐기됐거나 닿지 못하는 프록시로 설정돼 있으면, curl은 프록시의 호스트명을 해석하려다 실패하고 (6)을 보고합니다 — 애초에 문제가 아니던 당신의 타깃 호스트에 누명을 씌우면서요. 반대로, 작동하는 프록시를 우회해야 할 호스트가 no_proxy에 없으면, curl은 그걸 프록시로 보내고 프록시의 해석 실패를 물려받습니다. 환경을 확인하세요.

env | grep -i proxy

낡은 걸 지우거나 고치고 다시 실행하세요. 컨테이너와 CI에서는 이 변수들이 전역으로 주입돼 잊히는 경우가 많습니다.

DechoNet으로 진단

DNS 조회는 당신 머신 밖에서, 공개 리졸버로 호스트명을 해석합니다. 이게 결정타예요. DechoNet은 주소를 돌려주는데 로컬 getent/dig는 못 준다면, 그 이름은 공개 인터넷에서는 멀쩡하고 당신 문제는 로컬 — 리졸버, VPN, /etc/resolv.conf, 또는 프록시 변수 — 입니다. DechoNet도 해석 못 하면, 레코드가 정말로 없는 것(오타, 만료된 도메인, 없는 A/AAAA)이고, 로컬에서 아무리 고쳐도 소용없습니다.

확인 체크리스트

오류에 찍힌 정확한 호스트명의 오타·이상 문자·빈 변수를 다시 읽기.
curl 없이(getent hosts·dig·nslookup) 이름을 해석해 리졸버 문제와 curl 문제를 격리.
curl만 실패하면 env | grep -i proxy로 낡은 http_proxy/https_proxy를 지우고, 우회해야 할 호스트는 no_proxy에 추가.
/etc/resolv.conf가 실제로 닿을 수 있는 네임서버를 나열하는지 확인(특히 컨테이너 안에서).
그 이름이 유효해야 할 네트워크·VPN에 붙어 있는지 확인.
외부 DNS 조회로 레코드가 애초에 존재하는지 확인 — 로컬 문제와 진짜로 없는 레코드를 갈라줍니다.

사실은 7번 오류가 위장한 것일 때

이름이 어디서나 해석되는데 curl이 여전히 못 끝낸다면, 오류 번호를 다시 보세요. 해석이 성공하면 curl은 (6) 보고를 멈추고 접속으로 넘어갑니다 — 거부된 접속은 (7) Failed to connect, 멈춤은 (28) 타임아웃입니다. 그것들은 DNS가 아니라 포트·방화벽·서버 상태 문제이고, 다른 가이드의 영역입니다. 당신의 오류가 (6)이기를 멈추는 순간, 이름 해석 단계는 지나온 겁니다.

내 도메인에서 바로 확인

무료, 가입 불필요. 이 가이드가 다루는 항목을 바로 검사하고 조치 방법을 알려드립니다.