Could not resolve hostの対処｜curl・git・pip・npm

この記事で実際に動かしたもの：ループバックだけを持つ自分専用のネットワーク名前空間を作り、その中に DNS サーバー（dnsmasq）・Git と PyPI と npm レジストリのモック・プロキシを立てて、resolv.conf と hosts を差し替えながら名前解決にかかわる19の状況を起こし、各ツールのエラー原文、失敗するまでの時間、直したあとの出力を記録しました。

flowchart TD
    U[ホスト名] --> P{プロキシ設定?}
    P -->|あり| PX[プロキシ名を引く]
    PX -.->|失敗| E5[Could not<br>resolve proxy]
    P -->|なし| H{hosts?}
    H -->|なし| D{DNS?}
    D -.->|失敗| E6[Could not<br>resolve host]
    H -->|あり| OK[接続へ]
    D -->|IP| OK

やりたいことごとに、いちばん早い方法を先にまとめます。

確認環境：Ubuntu 24.04.5 LTS（Linux カーネル 6.18、glibc 2.39）の上で、curl 8.5.0、Git 2.43.0、Python 3.13.18 と pip 26.2.1、Node.js 22.23.4 と npm 10.9.9、GNU Wget 1.21.4、OpenSSH 9.6p1 を使いました。dig・nslookup（BIND 9.18.24）、dnsmasq 2.91、OpenSSH は Ubuntu の .deb を作業用のフォルダーに展開して使い、システムには入れていません。実験はすべて ip netns add t309 で作ったループバックだけのネットワーク名前空間の中で行い、その中でさらに unshare -m で自分のマウント名前空間を作って /etc/resolv.conf・/etc/hosts・/etc/nsswitch.conf を差し替えています。ホストの resolv.conf・hosts・プロキシの設定は変えていません。ホスト名は名前の衝突が起きないよう予約されたトップレベルドメイン .test（RFC 6761）を使い、DNS サーバー・Git のリポジトリ（dumb HTTP）・PyPI の simple インデックス・npm レジストリ・HTTP プロキシはすべてその名前空間の 127.0.0.1 に立てたモックで、外部のサービスには接続していません。Windows・Mac・Docker・WSL は手元で動かせないため、Microsoft Learn・Apple サポート・Docker Docs の公式ドキュメントで確かめた範囲だけを書いています。出力に出るパスは、読みやすさのため作業用のフォルダーを /work に置き換えました。図は mermaid で描画を確かめています（確認日 2026年11月6日）。

Could not resolve hostとは（エラー文の読み方と名前解決の流れ）

この節では、エラー文の各部分の意味と、ツールがホスト名を IP アドレスに変えるまでに何を読んでいるかが分かります。

通信の相手は IP アドレスで決まるため、ツールはまず URL のホスト名を IP アドレスに変えます（名前解決）。これに失敗したときに出るのが Could not resolve host です。相手のサーバーには、まだ1バイトも送っていません。

$ curl -sS http://reop.example.test/app.git/HEAD
curl: (6) Could not resolve host: reop.example.test
$ echo $?
6

読む場所は4つです。

名前解決は nsswitch.conf → hosts → resolv.conf → DNS の順

Linux の curl が名前を引くとき、どのファイルを開いて、どこへ問い合わせているかを strace で確かめました（存在しないファイルの行は省いています）。

$ strace -f -e trace=openat,connect curl -sS http://reop.example.test/
openat(AT_FDCWD, "/etc/nsswitch.conf", O_RDONLY|O_CLOEXEC) = 3
openat(AT_FDCWD, "/etc/resolv.conf", O_RDONLY|O_CLOEXEC) = 7
openat(AT_FDCWD, "/etc/hosts", O_RDONLY|O_CLOEXEC) = 7
connect(7, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("127.0.0.1")}, 16) = 0
curl: (6) Could not resolve host: reop.example.test

/etc/nsswitch.conf の hosts: files dns という行が「まず hosts ファイル（files）、無ければ DNS」という順番を決めています。hosts に無かったので、resolv.conf に書かれた DNS サーバー（127.0.0.1 の 53 番ポート）に問い合わせ、「その名前は無い」と返されて失敗しました。curl・git・pip・npm・wget・ssh は、どれもこの仕組み（glibc の getaddrinfo）を通って名前を引きます。

直したあと（正しい名前 repo.example.test）は、IP アドレスが決まってから接続に進みます。curl -v では、名前解決の結果が先に出ます。

$ curl -v http://repo.example.test:8080/
* IPv6: (none)
* IPv4: 127.0.0.1
*   Trying 127.0.0.1:8080...

「IPv4: 127.0.0.1」の行が出ていれば名前解決は済んでいて、そのあとの失敗は別の原因です（Connection refused・timed out との見分け方の節）。

Could not resolve hostの原因一覧（症状→原因→直し方）

この節では、手元で再現した原因を、症状から引ける一覧で確かめられます。

原因は「引く名前が違う」「DNS に届かない・答えない」「hosts・nsswitch で止まる」「プロキシの名前が引けない・プロキシを通らない」「コンテナや WSL の DNS が違う」の5つに分かれます。

まず1分で切り分ける（getent・dig・nslookupでの確かめ方）

この節では、Could not resolve host が出たときに最初に打つコマンドと、その結果から原因の見当を付ける方法が分かります。

「ツールの問題か、名前解決そのものの問題か」を先に分けます。getent hosts はツールと同じ仕組み（nsswitch.conf の順番どおり、hosts も見る）で名前を引き、dig と nslookup は DNS サーバーにだけ直接問い合わせます。

正しい名前を引いたときの3つのコマンドの出力です。

$ getent hosts repo.example.test
127.0.0.1       repo.example.test
$ dig +noall +answer +stats repo.example.test
repo.example.test.	0	IN	A	127.0.0.1
;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1) (UDP)
$ nslookup repo.example.test
Server:		127.0.0.1
Address:	127.0.0.1#53

Name:	repo.example.test
Address: 127.0.0.1

打ち間違えた名前では、getent は何も出さずに終了コード 2、dig は NXDOMAIN、nslookup は server can't find を返します。

$ getent hosts reop.example.test
$ echo $?
2
$ dig +noall +comments reop.example.test | grep status
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 64942
$ nslookup reop.example.test
Server:		127.0.0.1
Address:	127.0.0.1#53

** server can't find reop.example.test: NXDOMAIN

getent と dig で答えが違うときは hosts を疑う

/etc/hosts に誤った行（127.0.0.9 repo.example.test）を入れた状態で、2つを並べました。dig は hosts を読まないため DNS の答え（127.0.0.1）を出し、getent とツールは hosts の 127.0.0.9 を使います。

$ dig +short repo.example.test
127.0.0.1
$ getent hosts repo.example.test
127.0.0.9       repo.example.test

dig だけで「DNS は正しい」と判断すると、hosts やプロキシの問題を見落とします。ツールと同じ答えを見るのは getent、DNS サーバーの答えを見るのは dig、と使い分けます。dig と nslookup の詳しい使い方は、関連記事「nslookupの使い方｜逆引き・DNS指定・MX・エラーの意味を実例で」で扱っています。

原因1：ホスト名の打ち間違い・URLの貼り間違い

この節では、名前そのものが違うときの見分け方と、コマンドの書き方でホスト名が変わってしまう例が分かります。

DNS は正常で、存在しない名前を引いている状態です。dig が NXDOMAIN を返し、ほかのサイトは普通に引けるのが目印です。repo を reop と打ち間違えると、どのツールも名前をそのまま出して止まります。

$ curl -sS http://reop.example.test/app.git/HEAD
curl: (6) Could not resolve host: reop.example.test
$ git clone http://reop.example.test/app.git x
Cloning into 'x'...
fatal: unable to access 'http://reop.example.test/app.git/': Could not resolve host: reop.example.test
$ wget http://reop.example.test/
--2026-11-06 04:21:10--  http://reop.example.test/
Resolving reop.example.test (reop.example.test)... failed: Name or service not known.
wget: unable to resolve host address ‘reop.example.test’

名前を直すと、同じコマンドが通ります。

$ curl -sS http://repo.example.test/app.git/HEAD
ref: refs/heads/main
$ git clone http://repo.example.test/app.git
Cloning into 'app'...
$ echo $?
0

引用符の付け忘れで「application」を引いてしまう

検索で多いのが、ホスト名に覚えのない単語が出る例です。-H の値に空白があるのに引用符で囲まないと、シェルが空白で区切り、curl は application/json を2つ目の URL として扱います。

$ curl -X POST -H Content-Type: application/json -d '{"a":1}' http://repo.example.test/
curl: (6) Could not resolve host: application

-H 'Content-Type: application/json' のように値全体を引用符で囲むと、URL は1つだけになります。Windows のコマンドプロンプトは単一引用符を引用符として扱わないため、同じ書き方でも分割されます。コマンドプロンプトでは二重引用符を使い、JSON の中の二重引用符は \" と書きます。

二重の https://、全角空白、空白入りの名前

URL を貼り付けたときに起きやすい3つを、そのまま実行しました。

$ curl -sS https://https://repo.example.test/
curl: (6) Could not resolve host: https
$ curl -sS "http://repo.example.test　/"
curl: (6) Could not resolve host: repo.example.test
$ curl -sS "http://repo example.test/"
curl: (3) URL rejected: Malformed input to a URL function

2つ目は名前の末尾に全角空白が付いています。表示では普通の空白と区別しにくいため、エラーの名前の後ろに余白が見えたら、URL を打ち直すのが早道です。半角の空白は URL の書式の誤り（終了コード 3）として、名前解決の前に止まります。末尾のドット（repo.example.test.）は「これ以上補わない完全な名前」という意味で、名前解決は成功しました。

curl のオプションの書き方は、関連記事「curlコマンドの使い方とオプション一覧｜エラー対処・Windows・wget比較」で扱っています。

原因2：DNSサーバーに届かない（止まっている・応答しない・オフライン）

この節では、DNS サーバー側の状態によってエラーまでの時間がどう変わるかと、dig の返事で状態を見分ける方法が分かります。

どのホスト名でも失敗するなら、名前ではなく DNS サーバーへの経路が原因です。resolv.conf の nameserver を4通りに差し替え、同じ正しい名前（repo.example.test）を引いて時間を測りました。

dig の返事は、状態ごとに次の原文でした。

$ dig repo.example.test        # nameserver 127.0.0.2（止まっている）
;; communications error to 127.0.0.2#53: connection refused
;; no servers could be reached
$ dig repo.example.test        # nameserver 127.0.0.3（答えない）
;; communications error to 127.0.0.3#53: timed out
;; no servers could be reached
$ dig repo.example.test        # nameserver 192.0.2.53（経路が無い）
;; UDP setup with 192.0.2.53#53(192.0.2.53) for repo.example.test failed: network unreachable.
;; no servers could be reached

curl と git の文は、3つの状態のどれでも同じ Could not resolve host でした。違いが出るのは時間と、Python・Node.js のエラー番号です（ツール別のエラー文の節）。

10秒は resolv.conf の初期値で決まる

答えない DNS サーバーでは、curl が約10秒で諦めました。resolv.conf(5) の説明では、timeout の初期値は5秒（上限30）、attempts の初期値は2回（上限5）です。5秒×2回で10秒になり、getent hosts は IPv6 と IPv4 を順に引くため20秒かかりました。options で短くすると、待ち時間はそのまま縮みます。

$ cat /etc/resolv.conf
nameserver 127.0.0.3
options timeout:1 attempts:1
$ curl -sS http://repo.example.test/app.git/HEAD
curl: (6) Could not resolve host: repo.example.test
rc=6 elapsed=1.02s

1台目の DNS サーバーが答えず2台目が動いている場合、名前解決は成功しますが、毎回5秒待ってから2台目に移りました。「エラーにはならないが、どの通信も最初だけ5秒遅い」ときは、resolv.conf の1行目の DNS サーバーを疑います。

$ cat /etc/resolv.conf
nameserver 127.0.0.3
nameserver 127.0.0.1
$ curl -sS -o /dev/null -w '%{http_code}\n' http://repo.example.test/app.git/HEAD
200
rc=0 elapsed=5.03s

resolv.conf が空のときは自分のマシンに問い合わせる

resolv.conf を空にすると、resolv.conf(5) の「nameserver が無ければ、ローカルマシンのネームサーバーを使う」という動きになり、127.0.0.1 の DNS サーバーに問い合わせました。この環境では 127.0.0.1 で dnsmasq が動いていたため成功しましたが、通常のマシンでは 127.0.0.1 に DNS サーバーが無いため、止まっている場合と同じく即座に失敗します。

$ cat /etc/resolv.conf
$ nslookup repo.example.test
Server:		127.0.0.1
Address:	127.0.0.1#53

Name:	repo.example.test
Address: 127.0.0.1

ping は通るのに名前で繋がらない、といった切り分けの全体は、関連記事「ネットワークの切り分け8選｜pingは通るのに繋がらない」で扱っています。

原因3：/etc/hostsとnsswitch.confで名前解決が止まる

この節では、hosts ファイルで名前を固定したときの効き方と、nsswitch.conf の設定で DNS が使われなくなる例が分かります。

hosts ファイルは DNS より先に読まれ、書いてあればその IP アドレスが使われます。誤った IP アドレスを書いてもエラーは Could not resolve host にならず、接続の失敗（終了コード 7）になります。

$ grep example /etc/hosts
127.0.0.9 repo.example.test
$ curl -sS http://repo.example.test/app.git/HEAD
curl: (7) Failed to connect to repo.example.test port 80 after 3 ms: Couldn't connect to server
$ git ls-remote http://repo.example.test/app.git
fatal: unable to access 'http://repo.example.test/app.git/': Failed to connect to repo.example.test port 80 after 0 ms: Couldn't connect to server

逆に、DNS が使えない状態（resolv.conf が動いていない 127.0.0.53 を指す）でも、hosts に正しい行があれば名前解決は成功します。社内の検証サーバーなど、DNS に登録されていない名前を一時的に使うときの直し方です。

$ grep example /etc/hosts
127.0.0.1 repo.example.test pypi.example.test npm.example.test
$ getent hosts repo.example.test
127.0.0.1       repo.example.test pypi.example.test npm.example.test
$ git ls-remote http://repo.example.test/app.git
4e5b54a3ea6a6939a85819d0ea14fa48f02c7efb	HEAD
4e5b54a3ea6a6939a85819d0ea14fa48f02c7efb	refs/heads/main

hosts を書き換えずに1回だけ名前を固定する

hosts の編集には管理者権限が要り、戻し忘れると後で別の障害になります。確かめるだけなら、curl の --resolve と git の http.curloptResolve で、そのコマンドの中だけ名前と IP アドレスを結び付けられます。DNS が使えない状態で実行し、両方とも成功しました。

$ curl -sS --resolve repo.example.test:80:127.0.0.1 http://repo.example.test/app.git/HEAD
ref: refs/heads/main
$ git -c http.curloptResolve=repo.example.test:80:127.0.0.1 ls-remote http://repo.example.test/app.git
4e5b54a3ea6a6939a85819d0ea14fa48f02c7efb	HEAD
4e5b54a3ea6a6939a85819d0ea14fa48f02c7efb	refs/heads/main

これで通るなら、サーバーは動いていて、名前解決だけが原因だと切り分けられます。

nsswitch.conf の hosts に dns が無いと、dig は通るのにツールが失敗する

/etc/nsswitch.conf の hosts 行を hosts: files だけにすると、ツールは DNS を使わなくなります。dig は nsswitch.conf を読まずに DNS へ直接問い合わせるため、答えが食い違いました。

$ grep hosts /etc/nsswitch.conf
hosts: files
$ getent hosts repo.example.test
$ echo $?
2
$ dig +short repo.example.test
127.0.0.1
$ curl -sS http://repo.example.test/
curl: (6) Could not resolve host: repo.example.test

Ubuntu の初期値は hosts: files dns です（この環境の元の設定）。最小構成のコンテナや手で編集したサーバーで、dig だけ成功するときに確かめる行です。

原因4：プロキシの設定（Could not resolve proxy・no_proxy）

この節では、プロキシの設定の誤りで出る名前解決のエラーと、プロキシを通すと手元の DNS が要らなくなる仕組みが分かります。

プロキシを使う設定のとき、ツールが引くのは相手のホスト名ではなくプロキシのホスト名です。プロキシ名の綴りを誤ると、curl は Could not resolve proxy（終了コード 5）になります。DNS が使えない社内ネットワークを想定し、DNS を止めた状態で、hosts にプロキシの名前だけを書いて試しました。

$ export http_proxy=http://proxy.exmaple.test:3128
$ curl -sS http://repo.example.test/app.git/HEAD
curl: (5) Could not resolve proxy: proxy.exmaple.test
$ git clone http://repo.example.test/app.git px
Cloning into 'px'...
fatal: unable to access 'http://repo.example.test/app.git/': Could not resolve proxy: proxy.exmaple.test
$ pip install --retries 1 --index-url http://pypi.example.test/simple/ --trusted-host pypi.example.test hello-t309
Looking in indexes: http://pypi.example.test/simple/
WARNING: Retrying (Retry(total=0, connect=None, read=None, redirect=None, status=None)) after connection broken by 'NameResolutionError("HTTPConnection(host='proxy.exmaple.test', port=3128): Failed to resolve 'proxy.exmaple.test' ([Errno -3] Temporary failure in name resolution)")': http://pypi.example.test/simple/hello-t309/
ERROR: Could not find a version that satisfies the requirement hello-t309 (from versions: none)
ERROR: No matching distribution found for hello-t309
$ npm install --fetch-retries=0 --registry http://npm.example.test/ hello-t309   # npm_config_proxy も同じ綴り
npm error code EAI_AGAIN
npm error syscall getaddrinfo
npm error errno EAI_AGAIN
npm error request to http://npm.example.test/hello-t309 failed, reason: getaddrinfo EAI_AGAIN proxy.exmaple.test

pip と npm は proxy という語を出さず、名前の部分にプロキシのホスト名を書きます。エラーに出た名前が、接続したかった相手ではなくプロキシの名前になっていたら、プロキシの設定の問題です。綴りを直すと、DNS を止めたままでも4つとも成功しました。相手の名前はプロキシが引くため、手元の DNS は使われません。

$ export http_proxy=http://proxy.example.test:3128
$ curl -sS http://repo.example.test/app.git/HEAD
ref: refs/heads/main
$ git clone http://repo.example.test/app.git px
Cloning into 'px'...
$ pip install --index-url http://pypi.example.test/simple/ --trusted-host pypi.example.test hello-t309
Collecting hello-t309
  Downloading hello_t309-1.0.0-py3-none-any.whl (1.0 kB)
Installing collected packages: hello-t309
Successfully installed hello-t309-1.0.0
$ npm install --registry http://npm.example.test/ hello-t309
added 1 package in 243ms

プロキシのログには、ツールが名前を引かずに URL ごと渡してきた記録が残りました。

proxy GET http://repo.example.test/app.git/info/refs?service=git-upload-pack
proxy GET http://pypi.example.test/simple/hello-t309/
proxy GET http://npm.example.test/hello-t309

no_proxy に入れた名前は、プロキシを通らず手元で引く

no_proxy（npm は noproxy）に書いたドメインは、プロキシを通さず直接つなぎます。社内の DNS では外部の名前を引けない環境で、外部のドメインまで no_proxy に入れると、そのドメインだけ Could not resolve host になります。

$ export http_proxy=http://proxy.example.test:3128 no_proxy=.example.test
$ curl -sS http://repo.example.test/app.git/HEAD
curl: (6) Could not resolve host: repo.example.test
$ npm install --fetch-retries=0 --registry http://npm.example.test/ hello-t309   # npm_config_noproxy=.example.test
npm error code EAI_AGAIN
npm error request to http://npm.example.test/hello-t309 failed, reason: getaddrinfo EAI_AGAIN npm.example.test

ツールごとにプロキシの設定の置き場所が違うため、次のコマンドで全部を並べて見ます。

env | grep -i _proxy                 # 環境変数（curl・git・pip・npm が読む）
git config --show-origin --get-regexp 'http.*proxy'
npm config get proxy https-proxy noproxy
pip config list                       # PIP_PROXY・pip.conf の proxy

Git の http.proxy は、http_proxy・https_proxy・all_proxy の環境変数で設定するものを上書きする設定です（git-config）。npm の proxy と https-proxy は、HTTP_PROXY・HTTPS_PROXY の環境変数が設定されていればそれを使い、noproxy の初期値は NO_PROXY の値です（npm Docs）。pip は --proxy で指定でき、環境変数のプロキシも読みます（--no-proxy-env で読まなくできる）。プロキシの仕組みと認証（407）は、関連記事「プロキシとは？仕組みをわかりやすく｜PCの設定確認・開発ツール・407対処」で扱っています。

原因5：Docker・WSL・CIのコンテナ内のDNS

この節では、ホストでは引けるのにコンテナや WSL の中だけ Could not resolve host になる理由と、公式ドキュメントに書かれた直し方が分かります。

コンテナは自分のネットワーク名前空間を持つため、ホストの 127.0.0.53 や 127.0.0.1 は、コンテナの中からは別の場所（コンテナ自身のループバック）を指します。この記事の実験用の名前空間がまさにその状態で、ホストと同じように resolv.conf を 127.0.0.53 にすると、そこには何も動いていないため即座に失敗しました。

$ cat /etc/resolv.conf
nameserver 127.0.0.53
options edns0 trust-ad
$ curl -sS http://repo.example.test/app.git/HEAD
curl: (6) Could not resolve host: repo.example.test
$ dig repo.example.test
;; communications error to 127.0.0.53#53: connection refused
;; no servers could be reached

127.0.0.53 は systemd-resolved がループバックで待ち受けるスタブの DNS で、/etc/resolv.conf からのシンボリックリンクで使われます（systemd-resolved.service(8)）。ホストではこのスタブが答えますが、別の名前空間には届きません。resolv.conf を名前空間の中で動いている DNS（127.0.0.1）に向け直すと、同じコマンドが成功しました。

Docker：--dns と内蔵 DNS（127.0.0.11）

Docker Docs「Networking overview」では、次のように説明されています。

• コンテナは既定でホストと同じ DNS サーバーを使い、--dns で上書きできる。既定の bridge ネットワークでは、ホストのリゾルバー設定ファイルのコピーを受け取る
• ユーザー定義のネットワークのコンテナは、Docker の内蔵 DNS（127.0.0.11）を使い、外部の名前はホストに設定された DNS サーバーへ転送される
• --dns に書いたアドレスへの問い合わせはコンテナの名前空間から送られるため、ループバックのアドレスはコンテナ自身のループバックを指す
• ホストの /etc/hosts はコンテナに引き継がれない。追加するときは docker run の --add-host を使う

ホストで hosts に書いた名前がコンテナで引けないのは最後の項目のとおりで、--add-host で同じ行を渡します。DNS サーバーを変えるときは docker run --dns、すべてのコンテナに効かせるときはデーモン側の dockerd --dns（Docker Docs の dockerd リファレンスでは「DNS server to use」）で指定します。コンテナの中で getent hosts と cat /etc/resolv.conf を打つと、この記事と同じ手順で切り分けられます。

WSL：generateResolvConf と DNS トンネリング

Microsoft Learn「Advanced settings configuration in WSL」によると、wsl.conf の [network] の generateResolvConf は初期値 true で、WSL が /etc/resolv.conf を生成します。Windows 11 22H2 以降では .wslconfig の dnsTunneling（初期値 true）で DNS の問い合わせを Windows 側に渡し、そのとき resolv.conf に書かれる nameserver の初期値は 10.255.255.254 です。WSL の中で resolv.conf を手で書き換えても再起動で戻る場合は、generateResolvConf を false にしてから書きます。

CI：ランナーの DNS とプロキシ

CI のジョブの中で出るときも、確かめる順番は同じです。ジョブの最初に cat /etc/resolv.conf・getent hosts 相手の名前・env | grep -i _proxy を1行ずつ置くと、ランナーの DNS とプロキシの設定がログに残ります。社内の名前を引くジョブは、社内の DNS に届くランナーで動かします。

ツール別のエラー文（git・curl・pip・npm・wget・ssh・Python・Node.js）

この節では、同じ名前解決の失敗が各ツールでどう表示されるかと、エラー番号から「名前が無い」と「DNS に届かない」を見分ける方法が分かります。

名前が無いとき（NXDOMAIN）と、DNS に届かないとき（止まっている・答えない・経路が無い）では、Python と Node.js のエラー番号が変わります。curl・git・wget は同じ文のままです。

-2（ENOTFOUND）は「DNS は答えたが、その名前は無い」なので名前を見直し、-3（EAI_AGAIN）は「一時的に答えが得られない」なので DNS の経路を見ます。npm の全文は次のとおりで、名前が無い場合とプロキシの案内が一緒に出ます。

$ npm install --registry http://reop.example.test/ hello-t309
npm error code ENOTFOUND
npm error syscall getaddrinfo
npm error errno ENOTFOUND
npm error network request to http://reop.example.test/hello-t309 failed, reason: getaddrinfo ENOTFOUND reop.example.test
npm error network This is a problem related to network connectivity.
npm error network In most cases you are behind a proxy or have bad network settings.
npm error network
npm error network If you are behind a proxy, please make sure that the
npm error network 'proxy' config is set properly.  See: 'npm help config'
npm error A complete log of this run can be found in: /work/npmcache/_logs/2026-11-06T04_19_59_750Z-debug-0.log

pip は初期設定で5回やり直し、その都度 WARNING: Retrying を出してから ERROR: Could not find a version で終わります。最後の行だけ見ると「その版が無い」と読めますが、原因は上の WARNING 行にある名前解決の失敗です。

$ pip install --index-url http://reop.example.test/simple/ --trusted-host reop.example.test hello-t309
Looking in indexes: http://reop.example.test/simple/
WARNING: Retrying (Retry(total=4, connect=None, read=None, redirect=None, status=None)) after connection broken by 'NameResolutionError("HTTPConnection(host='reop.example.test', port=80): Failed to resolve 'reop.example.test' ([Errno -2] Name or service not known)")': /simple/hello-t309/
（同じ WARNING が total=3、2、1、0 で続く）
ERROR: Could not find a version that satisfies the requirement hello-t309 (from versions: none)
ERROR: No matching distribution found for hello-t309

やり直しで待たされる時間（npm 70.8秒・pip 7.9秒）

名前が無い場合でも、ツールはやり直しを続けます。初期設定のまま失敗するまでの時間を測りました。

npm install が長く止まって見えるときは、--fetch-retries=0 を付けて1回だけ試すと、原因の行がすぐ出ます。git の中で curl が何をしたかは、GIT_TRACE_CURL=1 で見られます。

$ GIT_TRACE_CURL=1 git ls-remote http://reop.example.test/app.git
04:29:20.796153 http.c:845              == Info: Could not resolve host: reop.example.test
04:29:20.796180 http.c:845              == Info: Closing connection
fatal: unable to access 'http://reop.example.test/app.git/': Could not resolve host: reop.example.test

SSH の URL（git@ホスト:リポジトリ）では、git ではなく ssh が名前を引くため、文言が変わります。

$ git ls-remote git@reop.example.test:app.git
ssh: Could not resolve hostname reop.example.test: Name or service not known
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.

「access rights」とありますが、権限の問題ではなく名前解決の失敗です。1行目の ssh: で始まる行が原因を表します。

Connection refused・timed outとの見分け方

この節では、名前解決の失敗と、そのあとの接続の失敗を、終了コードとエラー文で見分ける方法が分かります。

Could not resolve host は「相手の住所が分からない」、Connection refused は「住所に行ったが扉が閉まっていた」、timed out は「行ったが返事が無い」です。同じ名前空間で、4つの状態を並べて起こしました。

$ curl -sS http://reop.example.test/
curl: (6) Could not resolve host: reop.example.test
$ curl -sS http://repo.example.test:8080/
curl: (7) Failed to connect to repo.example.test port 8080 after 0 ms: Couldn't connect to server
$ curl -sS --max-time 3 http://repo.example.test:8081/
curl: (28) Operation timed out after 3002 milliseconds with 0 bytes received
$ curl -sS --proxy http://proxy.exmaple.test:3128 http://repo.example.test/
curl: (5) Could not resolve proxy: proxy.exmaple.test

Python と Node.js でも、名前解決の失敗と接続の拒否は別の例外・コードになりました。

gaierror [Errno -2] Name or service not known
ConnectionRefusedError [Errno 111] Connection refused
http://reop.example.test/ ENOTFOUND getaddrinfo ENOTFOUND reop.example.test
http://repo.example.test:8080/ ECONNREFUSED connect ECONNREFUSED 127.0.0.1:8080
http://repo.example.test:8081/ timeout

5・6・7・28 の意味は、libcurl のエラーコード一覧（libcurl-errors）の CURLE_COULDNT_RESOLVE_PROXY・CURLE_COULDNT_RESOLVE_HOST・CURLE_COULDNT_CONNECT・CURLE_OPERATION_TIMEDOUT と同じです。7 と 28 の原因と直し方は、関連記事「Connection refused・Read timed outの違いと直し方」で扱っています。

OS別の確かめ方と直し方（Windows・Mac・Linux）

この節では、OS ごとに名前解決を確かめるコマンドと、DNS の設定を見る場所が分かります。

どの OS でも「名前を引けるか」「どの DNS に聞いているか」「キャッシュに前の答えが残っていないか」の3つを見ます。Linux はこの記事で動かしたコマンド、Windows と Mac は公式ドキュメントで確かめた範囲です。

Windows

Microsoft Learn によると、Resolve-DnsName は nslookup と同様の DNS 問い合わせを行うコマンドレットで、-Server で問い合わせ先、-DnsOnly で DNS だけ、-NoHostsFile で hosts ファイルを飛ばして引けます。ipconfig /displaydns は hosts ファイルから読んだ項目と最近の答えを含むキャッシュを表示し、ipconfig /flushdns はキャッシュを消して、引けなかったという答え（ネガティブキャッシュ）も捨てます。DNS の設定を直したあとも失敗が続くときに使います。ipconfig の出力の読み方は、関連記事「ipconfigの使い方とMTUとは｜/all・/flushdnsとMTUの実例」で扱っています。

Resolve-DnsName github.com
Resolve-DnsName github.com -Server 1.1.1.1 -DnsOnly -NoHostsFile
nslookup github.com 1.1.1.1
ipconfig /flushdns

Mac

Apple の Mac ユーザガイド「Change DNS settings on Mac」では、DNS の設定はアップルメニュー → システム設定 → ネットワーク → ネットワークサービスを選ぶ → 詳細 → DNS で見られます。ターミナルの curl・git・pip・npm のエラー文は Linux と同じで、この記事の原因の見分け方がそのまま使えます。

Linux（systemd-resolved を使うディストリビューション）

/etc/resolv.conf が 127.0.0.53 だけを指しているときは、実際の DNS サーバーは resolvectl status で見ます。systemd の公式マニュアルでは、resolvectl status は今有効な全体とリンクごとの DNS 設定を表示し、resolvectl flush-caches はローカルのキャッシュを消します。

resolvectl status
resolvectl query github.com
resolvectl flush-caches

判断表：Could not resolve hostが出たらどこから確かめるか

この節では、手元の状況から最初に見る場所を決められます。

直すときに避けたいのが、原因を確かめないまま設定を書き換えることです。

再発を防ぐための確認項目です。

• 1エラーに出た名前を最初に読む相手の名前か、プロキシの名前か、意図しない語かで原因が分かれる
• 2getent と dig を両方打つ答えが違えば hosts・nsswitch・プロキシ、同じ失敗なら DNS
• 3エラー番号で名前と経路を分ける-2・ENOTFOUND は名前、-3・EAI_AGAIN は DNS への経路
• 4プロキシの設定を1か所にまとめる環境変数・git config・npm config・pip.conf に別々の値を残さない
• 5hosts の一時的な行は戻す確かめるだけなら --resolve を使い、hosts は書き換えない

よくある質問

Q. Could not resolve host は相手のサーバーが落ちているという意味ですか？
いいえ。名前を IP アドレスに変える段階で止まっており、相手のサーバーにはまだ接続していません。サーバーが止まっている場合は、名前解決が済んだあとの Connection refused か timed out になります。

Q. ブラウザでは開けるのに、curl や git だけ失敗します。
ブラウザだけにプロキシが設定されている（OS やブラウザのプロキシ設定、PAC ファイル）ことが多いです。ターミナルのツールは環境変数や各ツールの設定を読むため、env | grep -i _proxy と git config・npm config のプロキシを見ます。

Q. curl: (6) と curl: (5) の違いは何ですか？
6 は接続したい相手の名前、5 はプロキシの名前を引けなかったという意味です。5 のときは相手の URL ではなく、http_proxy などに書いたプロキシのホスト名を直します。

Q. Temporary failure in name resolution と Name or service not known はどう違いますか？
Name or service not known（-2）は DNS が「その名前は無い」と答えた場合、Temporary failure in name resolution（-3）は DNS から答えが得られなかった場合です。前者は名前、後者は DNS への経路を確かめます。

Q. npm install が1分以上止まってから ENOTFOUND になります。
初期設定では fetch-retries が2回で、間に10秒以上待つため、この環境では70.8秒かかりました。--fetch-retries=0 を付けると1回で失敗し、原因の行がすぐ出ます。

Q. pip が「Could not find a version」と言いますが、パッケージ名は正しいはずです。
上に WARNING: Retrying … NameResolutionError が出ていれば、インデックスに届いていないため一覧が空になっています。名前解決を直すと、同じパッケージがそのまま見つかります。

Q. /etc/hosts に書けば直りますか？
名前と IP アドレスの組が正しければ直ります。ただし IP アドレスが変わっても hosts の値が使われ続け、Connection refused などの別のエラーになります。確かめる目的なら curl --resolve や git -c http.curloptResolve で、そのコマンドの中だけ固定する方法が安全です。

Q. Docker のコンテナの中だけ名前が引けません。
コンテナの中で cat /etc/resolv.conf を見ます。ホストの 127.0.0.53 のようなループバックはコンテナの中では別の場所を指すため、docker run --dns（全体なら dockerd --dns）で届く DNS を指定します。ホストの hosts に書いた名前は引き継がれないため、--add-host で渡します。

Q. WSL で resolv.conf を直しても、再起動すると元に戻ります。
wsl.conf の generateResolvConf が初期値の true だと、WSL が resolv.conf を生成し直します。手で書く場合は [network] に generateResolvConf = false を書いてから編集します。

Q. DNS を直したのに、しばらく同じエラーが続きます。
DNS のキャッシュに「引けなかった」という答えが残っている場合があります。Windows は ipconfig /flushdns、systemd-resolved を使う Linux は resolvectl flush-caches で消せます。

まとめ

• Could not resolve host は、ホスト名を IP アドレスに変えられなかったという意味。相手のサーバーには接続しておらず、名前・DNS・hosts・プロキシ・コンテナの DNS のどこかで止まっている。
• 最初にエラーに出た名前を読み、getent hosts（ツールと同じ経路）と dig（DNS だけ）を打つ。答えの食い違いで hosts・nsswitch・プロキシと DNS を分けられる。
• dig の返事が NXDOMAIN なら名前、connection refused なら DNS の停止、timed out なら応答なし（約10秒待つ）、network unreachable なら経路の問題。pip・Python の -2 と -3、npm の ENOTFOUND と EAI_AGAIN も同じ分かれ方。
• プロキシ名を誤ると curl は (5) Could not resolve proxy、pip・npm はプロキシ名を出して失敗する。正しいプロキシを通せば手元の DNS が使えなくても通り、no_proxy に入れた名前は手元で引く。
• Docker・WSL・CI では中の resolv.conf を見て、--dns・--add-host・wsl.conf で直す。確かめるだけなら curl --resolve と git -c http.curloptResolve を使う。

名前解決が通ったあとに Connection refused や timed out が出たときは Connection refused・Read timed out の記事、プロキシの認証で 407 が出たときはプロキシの記事が次の一歩になります（いずれも本文中でリンクしています）。

参考・出典

確認日はいずれも 2026年11月6日です。

• curl「libcurl - Error Codes」（CURLE_URL_MALFORMAT・CURLE_COULDNT_RESOLVE_PROXY・CURLE_COULDNT_RESOLVE_HOST・CURLE_COULDNT_CONNECT・CURLE_OPERATION_TIMEDOUT）：https://curl.se/libcurl/c/libcurl-errors.html
• Linux man-pages「resolv.conf(5)」（nameserver が無い場合・timeout・attempts の初期値）：https://man7.org/linux/man-pages/man5/resolv.conf.5.html
• systemd「systemd-resolved.service」（127.0.0.53 のスタブ・stub-resolv.conf）：https://www.freedesktop.org/software/systemd/man/latest/systemd-resolved.service.html
• systemd「resolvectl」（status・query・flush-caches）：https://www.freedesktop.org/software/systemd/man/latest/resolvectl.html
• Git「git-config」の http.proxy・http.curloptResolve：https://git-scm.com/docs/git-config
• npm Docs「config」（proxy・https-proxy・noproxy・fetch-retries・fetch-retry-mintimeout・fetch-retry-maxtimeout）：https://docs.npmjs.com/cli/v11/using-npm/config
• pip documentation「pip」General Options（--proxy・--retries・--timeout・--trusted-host・--no-proxy-env）：https://pip.pypa.io/en/stable/cli/pip/
• Docker Docs「Networking overview」（DNS services・Custom hosts）：https://docs.docker.com/engine/network/
• Docker Docs「dockerd」（--dns・--dns-opt・--dns-search）：https://docs.docker.com/reference/cli/dockerd/
• Microsoft Learn「Advanced settings configuration in WSL」（generateResolvConf・dnsTunneling）：https://learn.microsoft.com/en-us/windows/wsl/wsl-config
• Microsoft Learn「ipconfig」：https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/ipconfig
• Microsoft Learn「nslookup」：https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/nslookup
• Microsoft Learn「Resolve-DnsName」：https://learn.microsoft.com/en-us/powershell/module/dnsclient/resolve-dnsname
• Apple「Mac User Guide: Change DNS settings on Mac」：https://support.apple.com/guide/mac-help/change-dns-settings-on-mac-mh14127/mac
• IETF「RFC 6761 Special-Use Domain Names」（.test）：https://www.rfc-editor.org/rfc/rfc6761

株式会社RJC ― SI事業・SES事業・AI駆動開発。RJCは一緒に成長を楽しめる会社です。