开启WireGuard VPN时，WSL2镜像网络下Docker调用Azure翻译API失败

• VPN路由规则未覆盖容器网络
  开启networkingMode=mirrored后，WSL宿主机能继承Windows的WireGuard路由，但Docker容器的网络栈可能未正确获取针对Azure翻译API目标IP（20.43.132.97）的VPN路由。检查Windows侧WireGuard配置的AllowedIPs是否包含该Azure IP段，或者是否存在规则仅允许WSL宿主机流量走VPN，导致容器流量走公网链路，形成单向通信（Client Hello发出后，服务器响应走VPN返回，容器无法接收）。

• TLS版本/加密套件兼容性差异
  容器内的精简镜像（如Python 3.12.2-slim）使用的TLS库（如OpenSSL）默认支持的加密套件或TLS版本，可能和VPN链路下Azure API的要求不匹配，而WSL宿主机的系统TLS配置更完整。可以强制curl使用TLS 1.2测试：

  curl -v --tlsv1.2 "https://api.cognitive.microsofttranslator.com/translate?api-version=3.0&from=en&to=es" \
    -H "Ocp-Apim-Subscription-Key: xxx" \
    -H "Content-Type: application/json; charset=UTF-8" \
    -d "[{'Text':'Hello friend.'}]"
  

• MTU不匹配导致数据包丢失
  WireGuard通常会设置较小的MTU（如1420），而Docker容器默认MTU为1500。容器发出的TLS握手包加上VPN封装后超过MTU，若中间网络不允许分片，会导致包丢失，卡在握手阶段。可尝试修改容器MTU与WireGuard一致：

  docker run --mtu=1420 -it your-image-name bash
  

  或修改Docker daemon配置文件/etc/docker/daemon.json添加"mtu": 1420后重启Docker。

• Windows防火墙拦截容器流量
  开启VPN后，Windows防火墙可能新增规则允许WSL宿主机流量通过VPN，但未授权Docker容器的出站流量。检查Windows防火墙高级设置，确认存在允许容器访问Azure API IP（20.43.132.97）及443端口的出站规则。

• DNS解析后路由链路不一致
  容器解析到的Azure API IP为20.43.132.97，但容器内该IP的路由未走VPN，导致服务器响应走VPN返回，容器无法接收。在容器内执行以下命令查看路由：

  ip route get 20.43.132.97
  

  对比WSL宿主机的同命令结果，确认路由是否一致。

内容的提问来源于stack exchange，提问作者AntonOfTheWoods