telepresence 连不上本地 go 服务，因默认不代理所有端口且不注入 k8s 环境变量；需显式指定 --port、监听 :8080 而非 127.0.0.1、手动补环境变量，并注意 x-forwarded-for 不自动透传。
Telepresence 连不上本地 Go 服务？检查 telepresence intercept 的端口映射逻辑
Telepresence 不是代理所有端口，它只转发你在 intercept 命令里明确指定的端口。Go 服务默认监听 localhost:8080，但如果你没在 telepresence intercept 中声明 --port 8080:8080，K8s 集群里的调用根本不会落到你本地进程上。
常见错误现象：curl http://my-service.default.svc.cluster.local 返回 502 或超时，telepresence status 显示 intercept 已激活，但本地 netstat -an | grep 8080 没有监听 —— 说明端口没透传过去。
- 务必显式加
--port：例如telepresence intercept my-deployment --port 8080:8080 --env-file .env - Go 服务启动时不能绑定
127.0.0.1:8080，得用:8080（即监听所有接口），否则 Telepresence 的反向代理连不上 - 如果 Go 用了
http.Server.Addr，确认它不是硬编码为"127.0.0.1:8080"；建议设为":8080"或通过环境变量注入
Go 程序热重载失效？别让 air 或 fresh 和 Telepresence 的网络栈冲突
Telepresence 启动后会修改本地 DNS 和路由表，部分热重载工具（比如 air）依赖 inotify 或 fsnotify 监控文件变化，本身不感知网络层变动，但它们重启进程时可能沿用旧的网络配置或未清理 socket，导致新实例无法绑定端口，或仍走宿主机 DNS 而非 Telepresence 的 CoreDNS。
使用场景：你改了 main.go，air 重启了服务，但 curl 集群内地址仍然打不到最新代码 —— 很可能是端口被占，或新进程没正确监听。
立即学习“go语言免费学习笔记（深入）”；
- 启动前先停掉其他占用目标端口的进程：
lsof -i :8080 | grep LISTEN | awk '{print $2}' | xargs kill -
air配置里加stop_on_error: true，避免崩溃后残留僵尸进程 - 推荐用
go run+ 手动重启（简单项目）或nodemon -x "go run main.go"（更轻量，对 Telepresence 更友好）
为什么 os.Getenv("KUBERNETES_SERVICE_HOST") 在本地 Go 里返回空？Telepresence 不自动注入 K8s 环境变量
Telepresence 默认只做流量劫持和 DNS 替换，它不会把 Pod 的环境变量（如 KUBERNETES_SERVICE_HOST、NAMESPACE、自定义 ConfigMap 注入的变量）同步到你的本地进程。而很多 Go 项目直接读这些变量来构造 API 地址或切换配置，一跑就 panic。
性能影响：手动补环境变量无开销；但若用 --env-file 加载大量变量，每次 intercept 启动会多几百毫秒解析时间，可忽略。
- 最简方案：运行前导出关键变量：
export KUBERNETES_SERVICE_HOST=10.96.0.1; export KUBERNETES_SERVICE_PORT=443 - 进阶做法：用
kubectl get pod my-pod -o yaml提取 env 块，过滤出非 secret 类型变量，生成临时.tele-env，再传给telepresence intercept --env-file .tele-env - 注意
ConfigMap和Secret类型的 env 不会被自动展开，需提前kubectl get cm xxx -o jsonpath='{.data.KEY}'手动提取
调试时发现 Go 日志里 IP 是 127.0.0.1？Telepresence 的请求头 X-Forwarded-For 并不默认透传
Go 的 http.Request.RemoteAddr 在 Telepresence 下显示为 127.0.0.1:xxxx，不是上游真实客户端 IP。这不是 bug，而是 Telepresence 当前版本（v2.25+）默认不转发原始 X-Forwarded-For，也不重写 RemoteAddr —— 它只保证流量可达，不模拟 Ingress 行为。
容易踩的坑：你写了按 IP 限流或地域判断逻辑，本地联调时全走 127.0.0.1，上线后行为突变。
- 若需真实客户端 IP，必须在集群侧 Ingress（如 Nginx Ingress）开启
use-forwarded-headers: "true"，并确保 Telepresence 流量经过该 Ingress - Go 代码里别直接信
r.RemoteAddr，改用r.Header.Get("X-Forwarded-For")，并校验来源可信（比如只接受来自10.0.0.0/8或 Ingress CIDR 的头） - Telepresence 本身不提供
--trust-xff类参数，这个逻辑必须由你控制
复杂点在于：Telepresence 的拦截是透明的，但它不参与 HTTP 层语义解析。任何依赖请求头、TLS 客户端证书、或原始 socket 信息的 Go 逻辑，在本地联调时都得额外适配 —— 这不是配置问题，是架构层面的隔离假设差异。
