curl

Deux commandes, et la distinction entre elles constitue tout l’intérêt.

curl-host

S’exécute dans l’espace de noms réseau de l’hôte — la connectivité propre du nœud, avant toute intervention du plan de données.

{"command":["curl-host","-v","cloud.f5.com"]}

  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0*   Trying <public-ip>:80...
* Connected to cloud.f5.com (<public-ip>) port 80 (#0)
> GET / HTTP/1.1
> Host: cloud.f5.com
> User-Agent: curl/7.76.1
> Accept: */*
>
* Mark bundle as not supporting multiuse
< HTTP/1.1 301 Moved Permanently
< location: https://cloud.f5.com/
< server: volt-adc
< date: Mon, 03 Aug 2026 16:30:24 GMT
< connection: close
< content-length: 0
<
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0
* Closing connection 0

curl-vega

S’exécute dans le contexte Vega (plan de contrôle) plutôt que dans celui de l’hôte. La différence observable, et la seule établie ici, est l’environnement dont elle hérite : curl-vega signale une liste NO_PROXY couvrant les plages privées, int.ves.io, int.volterra.us et le domaine .tenant.local propre au site, tandis que curl-host n’en signale aucune. Ce que cela implique quant au chemin DNS n’est pas mesuré.

{"command":["curl-vega","-v","cloud.f5.com"]}

* Uses proxy env variable NO_PROXY == '10.0.0.0/8,172.16.0.0/12,192.168.0.0/16,100.127.0.0/18,100.127.192.0/18,169.254.0.0/16,int.ves.io,int.volterra.us,mcn-ce-ha-eastus01.<tenant>.tenant.local'
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0*   Trying <public-ip>:80...
* Connected to cloud.f5.com (<public-ip>) port 80 (#0)
> GET / HTTP/1.1
> Host: cloud.f5.com
> User-Agent: curl/7.76.1
> Accept: */*
>
* Mark bundle as not supporting multiuse
< HTTP/1.1 301 Moved Permanently
< location: https://cloud.f5.com/
< server: volt-adc
< date: Mon, 03 Aug 2026 16:30:26 GMT
< connection: close
< content-length: 0
<
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0
* Closing connection 0

La paire constitue une bissection

Exécutez les deux. Si curl-host réussit et que curl-vega échoue, le nœud dispose de la connectivité et quelque chose dans le contexte du plan de contrôle ne fonctionne pas — ses paramètres de proxy ou son résolveur. Si les deux échouent, le problème se situe en amont du nœud : routage, pare-feu ou chemin de sortie. Si seul curl-host échoue, vous avez trouvé quelque chose d’inhabituel et devriez d’abord vérifier la table de routage de l’hôte.

Sur un nœud sain, les deux réussissent et atteignent la même adresse ; une paire correcte ne prouve donc rien quant au contexte utilisé — c’est la divergence qui porte l’information.

Les deux acceptent les arguments curl habituels sous forme d’éléments de tableau distincts. Il vaut la peine de conserver -v, car les lignes relatives à la connexion et à la négociation TLS sont généralement là où l’échec se manifeste.