minikube 无法访问私有 API？先检查驱动

宿主机、节点和 Pod 各有自己的路由和解析器。先确认驱动，再从三处测试同一端点，最后修复真正失败的那一层。

私有 API 从你的笔记本上能应答，而 minikube 里的 Pod 却访问不到。在改宿主机上的任何配置之前，先确认当前配置档背后用的是哪种驱动，因为这一条事实就决定了请求实际从哪个网络发出。然后分别从宿主机、节点和 Pod 测试同一个端点。三者之中只有一个才是真正失败的那一层，猜错就要耗掉一个下午。

第 0 步：确认驱动和请求来源

问 minikube 当前哪个配置档在运行、它是怎么跑的。容器驱动会把节点放进你机器上的一个容器里，VM 驱动会把节点放进虚拟机，远程驱动则把它放到完全不同的地方。

minikube profile list
minikube status
kubectl config current-context

据此写下请求的来源。答案决定了该看谁的解析器、哪些路由才算数，而且并不总是宿主机的。同一台笔记本上的两个配置档，对同一个 URL 也可能表现完全不同。

ContextWhat has to work
Host processHost resolver and host route to the private destination
minikube nodeThe node's own resolver and its outbound path
PodPod DNS through cluster services plus the cluster network path

第 1 步：把同一个端点测三次

挑一个无害的端点，三次测试都保持主机名、端口和地址族完全一致。中途改动其中任何一项，结果就没有可比性。

curl -sS -o /dev/null -w '%{http_code}\n' https://api.corp.example/health
minikube ssh -- curl -sS -o /dev/null -w '%{http_code}\n' https://api.corp.example/health
kubectl run probe --rm -it --image=curlimages/curl --restart=Never -- \
  curl -sS -o /dev/null -w '%{http_code}\n' https://api.corp.example/health

节点成功拉取镜像，并不能证明私有主机的域名解析没问题。公网请求成功就更说明不了什么。按上下文把结果分开记录，因为三行里出现规律才是诊断，单次失败只是线索。

如果宿主机那一行也失败，就停下来。这是宿主机的网络问题，跟集群无关。

第 2 步：保住宿主机到集群的路径

还有第二个方向常被忽略：宿主机必须始终能访问集群自己的 API 和服务。VPN 客户端可能安装了一些路由，与 minikube 用于节点网络、服务网段和 Pod 网段的前缀发生冲突。

一旦发生冲突，症状很迷惑人：隧道明明通着，kubectl 却不再响应，或者 NodePort 拒绝连接。看起来像集群故障，实际上是笔记本的路由故障。

在把问题归咎于隧道之前，先拿宿主机的路由表和 minikube 的网段对照。重叠通常表现为一条更具体的路由指向隧道接口，而那个前缀本应属于集群。

第 3 步：不关 VPN 也能解决重叠

minikube 自己的 VPN 与代理手册讨论过这些冲突，并把其中的示例网段当作需要核查的对象，而不是通用清单。请结合你实际使用的配置档来读。

如果确实存在重叠，受支持的答案是改用不重叠的网段，或者由 VPN 归属方批准的、有意为之的本地访问策略。改服务网段和改 Pod 网段不是一回事，两者也都不等于改节点网络。

为了让本地集群能用就关掉公司隧道，这不是什么变通办法，而是必须由别人做的策略决定。请去找那位负责人，而不是等大家都下班后悄悄动手。如果你已经这么做了，先恢复再提问。

第 4 步：分清代理、DNS 和四种故障形态

如果需要代理，先确认是哪一层需要。宿主机上的浏览器设置管不到节点里的进程，而 Pod 需要环境变量或集群级代理配置。

然后给故障分类，而不是描述它。解析不出来的名字是 DNS。能解析但拒绝连接的是路由或监听器。连上了却卡在身份验证的是 TLS。连上了但返回错误响应体的是应用本身。

这四类各自对应不同的修法，而且只有一类跟 VPN 有关。把每一层观察到的情况写下来，下一个人接到的就是证据，而不是故事。

相关文章