What happened:

kind build node-image ./ fails when HTTP_PROXY / HTTPS_PROXY point to a localhost proxy on the host, for example http://127.0.0.1:12334.

I use a local VLESS client (v2rayN) that exposes an HTTP proxy on 127.0.0.1:12334 on the host. During the build, kind creates a kind-build-* container, forwards proxy env vars into it, and then pulls required images inside that container via ctr. Because 127.0.0.1 inside the build container is not the host loopback, those pulls fail.

Example failure:

Failed to pull registry.k8s.io/etcd:3.6.8-0 with error: command "docker exec --privileged kind-build-1776360268-382215769 ctr --namespace=k8s.io content fetch --platform=linux/amd64 registry.k8s.io/etcd:3.6.8-0" failed with error: exit status 1
time="2026-04-16T17:24:32Z" level=info msg="fetch failed" error="failed to do request: Head \"https://registry.k8s.io/v2/etcd/manifests/3.6.8-0\": proxyconnect tcp: dial tcp 127.0.0.1:12334: connect: connection refused" host=registry.k8s.io
ctr: failed to resolve reference "registry.k8s.io/etcd:3.6.8-0": failed to do request: Head "https://registry.k8s.io/v2/etcd/manifests/3.6.8-0": proxyconnect tcp: dial tcp 127.0.0.1:12334: connect: connection refused

This affects other pulls as well (pause, coredns, kindnetd, local-path-*, etc.).

What you expected to happen:

Either:

1. kind supports running the build container with host networking, for example via KIND_NODE_IMAGE_BUILD_CONTAINER_HOSTNETWORK=true, so localhost-based host proxies work.
2. kind fails early when HTTP_PROXY / HTTPS_PROXY point to localhost / 127.0.0.1, with a clear message to unset those variables or opt into host networking.

How to reproduce it (as minimally and precisely as possible):

1. Run a local HTTP proxy on the host at 127.0.0.1:12334.
2. Export:
   • HTTP_PROXY=http://127.0.0.1:12334
   • HTTPS_PROXY=http://127.0.0.1:12334
3. Run:

   kind build node-image ./

4. Observe that the build reaches the node image phase, creates a kind-build-* container, and then fails when ctr tries to pull required images from inside that container.

Anything else we need to know?:

This seems worth handling explicitly because localhost proxies on the host are a valid setup. A clear early error would be the safer default; an opt-in host-network mode would provide an escape hatch.

Environment:

• kind version: kind v0.31.0 go1.25.9 X:nodwarf5 linux/amd64
• Runtime info: Docker
• OS (e.g. from /etc/os-release): Fedora Linux 43 (Workstation Edition)
• Kubernetes version: kubectl client v1.35.1
• Any proxies or other special environment settings?:
  • HTTP_PROXY=http://127.0.0.1:12334
  • HTTPS_PROXY=http://127.0.0.1:12334
  • local host proxy provided by v2rayN