virtualservice流量未生效因hosts字段未匹配请求host头；grpc需用fqdn避免mtls证书校验失败；header匹配须注意大小写与空格；sidecar注入后需调整readinessprobe并确保iptables规则正常。
流量路由没生效？检查 VirtualService 的 hosts 字段是否匹配实际请求 Host
很多人写完 VirtualService 发现灰度流量根本没切过去，curl 也还是打到老版本——问题常出在 hosts 值填了服务名（比如 "productsvc"），但客户端发请求时 Host 头是域名（比如 "product.example.com"）。Istio 路由匹配的是 HTTP/HTTPS 请求的 Host 头或 TLS SNI，不是 Kubernetes Service 名。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
-
hosts必须和客户端真实发出的 Host 一致；若走 Ingress Gateway，通常填你配置的网关域名 - 用
istioctl proxy-config routes -n istio-system deploy/istio-ingressgateway看实际生效的路由规则，确认 host 条目是否被加载 - 如果应用本身不带 Host 头（比如直接 curl ClusterIP），HTTP 流量不会触发
VirtualService中的 HTTP 路由逻辑，得改用DestinationRule+ subset +weight在 TCP 层做分流
Golang 应用启用了 mTLS 却连不上？确认 Sidecar 注入后证书路径和 gRPC Dial 选项
Istio 默认启用 STRICT mTLS 后，Golang 客户端若直接用 grpc.Dial("productsvc:8080") 会报 x509: certificate is valid for ingressgateway.istio-system.svc.cluster.local, not productsvc ——因为服务间通信走的是 Pod IP 或 ClusterIP，而 Istio 签发的证书 Subject Alternative Name（SAN）只包含 *.namespace.svc.cluster.local 格式，不包含短服务名或 IP。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 客户端必须用 FQDN（如
"productsvc.default.svc.cluster.local:8080"）发起 gRPC 调用，否则证书校验失败 - 若用
http.Client调 HTTP 服务，无需额外配置 TLS；但若手动设置了Transport.TLSClientConfig，反而可能覆盖 Sidecar 提供的透明 TLS，导致握手失败 - 本地开发联调时，别在 Golang 代码里硬编码
tls.Config，让流量自然流经 Sidecar 更安全可靠
想按请求头做灰度，但 match 规则总不命中？注意 header key 大小写和空格处理
Istio 的 headers 匹配默认区分大小写，且会严格比对值（包括前后空格）。写 match: [{ headers: { "x-user-id": { exact: "123" } } }]，但如果前端传的是 X-User-ID: "123 "（带尾部空格），这条规则就完全失效。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 用
istioctl proxy-status确认对应 Pod 的 Envoy 配置已同步，再用istioctl proxy-config listeners -n default deploy/productsvc --port 8080 -o json | jq '.[0].filterChains[0].filters[0].typedConfig.routeConfig.virtualHosts[0].routes'查看实际生效的 match 条件 - 优先用
prefix或regex替代exact，比如regex: "^123.*"更容错 - Header key 推荐全小写（
x-user-id），避免因客户端实现差异导致匹配失败；Envoy 内部统一转为小写处理
Sidecar 注入后 Golang 应用启动变慢甚至超时？调整 readinessProbe 和 init 容器依赖
默认注入 Sidecar 后，Pod 启动流程变成：init 容器 → iptables 规则设置 → Sidecar 启动 → 主容器启动。而 Golang 应用若在 main() 里就尝试连接数据库或下游服务，此时 Sidecar 还没 ready，DNS 解析或 outbound 流量会被拦截丢弃，导致 panic 或启动卡住。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 主容器的
readinessProbe必须指向应用自身健康端点（如/healthz），**不能**探活localhost:15021/healthz/ready（那是 Sidecar 的就绪接口） - Init 容器默认无超时限制，但若集群 DNS 响应慢，iptables 初始化可能卡住；可在注入时加注解
sidecar.istio.io/interceptionMode="TPROXY"减少依赖 - Golang 应用内部不要在初始化阶段强依赖外部服务；改用 lazy init 或重试机制，等 Sidecar 就绪后再建连
最易被忽略的一点：Istio 的流量劫持是「有状态」的——它依赖 iptables 规则 + Envoy 的 listener 配置。任何手动修改 iptables、重启 kube-proxy、或误删 istio-init 容器，都会让流量静默失败，且日志里几乎不报错。排查时先看 iptables -t nat -L ISTIO_REDIRECT 是否存在，再查 istioctl proxy-status 中该 Pod 的 SYNCED 状态。
