Commande terminal

[versed cairn]

Il faut taper quoi dans le terminal pour ouvrir la discussion avec mon agent sur internet

[bitter sundial]

To help others find answers, you can mark your question as solved via Right click solution message -> Apps -> ✅ Mark Solution

[north tree]

Le plus simple :

• Interface web / chat : openclaw dashboard
• Afficher juste le lien : openclaw dashboard --no-open
• Parler directement à l’agent depuis le terminal : openclaw agent --message "Salut"

Si tu veux l’ouvrir à distance / sur internet, le chemin recommandé est plutôt :

• openclaw gateway --tailscale serve

Docs :

• https://docs.openclaw.ai/cli/dashboard
• https://docs.openclaw.ai/web/control-ui
• https://docs.openclaw.ai/tools/agent-send

Si openclaw n’est pas reconnu, lance openclaw --version et colle le résultat ici.

[versed cairn]

Ok c’est bon j’ai trouver mon ouvris il faut taper quoi dans le terminal pour mettre la dernière MAJ

[north tree]

Pour une install classique d’OpenClaw, la commande c’est simplement :

openclaw update

Si tu veux juste voir ce qu’il va faire avant :

openclaw update --dry-run

Et après, tu peux vérifier la version :

openclaw --version

Docs :

• https://docs.openclaw.ai/install/updating
• https://docs.openclaw.ai/cli/update

Si tu l’as installé avec Docker / Hostinger / Railway / autre, la commande n’est pas forcément la même, donc dans ce cas dis-moi comment tu l’as installé.

[versed cairn]

La dernière mise à jour charge depuis 10 min c’est normal ?

[north tree]

Oui, 10 min peut encore être normal 👍

Surtout si tu es en install git/source, parce que l’update peut :

• récupérer les dépendances,
• rebuild OpenClaw + le Control UI,
• lancer openclaw doctor.

Dans les docs, le timeout par étape est de 1200s, donc 20 min.
Donc à 10 min, ce n’est pas forcément bloqué.

Par contre, si :

• ça n’affiche plus rien du tout pendant longtemps,
• ou ça dépasse 20 min,

alors colle ici :

openclaw --version
openclaw update status

et dis aussi si tu l’as installé via npm / git / Docker.

Docs :

• https://docs.openclaw.ai/cli/update
• https://docs.openclaw.ai/install/updating

[versed cairn]

Je l’ai installé via mon terminal

[north tree]

Oui, mais ça peut être npm ou git/source, donc ça change un peu 🙂

Pour savoir lequel tu as, colle-moi juste ça :

openclaw --version
openclaw update status

Si tu as installé avec la commande du style :

curl -fsSL https://openclaw.ai/install.sh | bash

alors 10 min peut encore être normal pendant le build.

Si tu veux, envoie la sortie des 2 commandes et je te dis direct si c’est normal ou bloqué.

[versed cairn]

Attend pour l’instant j’attend que ça fasse plus de 20 min

[north tree]

Oui, bonne idée.

Tant que ça affiche encore de nouvelles lignes, laisse-le bosser.
Si ça dépasse 20 min ou que ça reste figé sans aucun nouveau texte, reviens avec :

openclaw --version
openclaw update status

et si possible une capture ou les dernières lignes du terminal.

[versed cairn]

Et c’est bon j’ai trouver en haut de mon terminal c’est marquer nmp

Npm *

[north tree]

Parfait, donc c’est sûrement npm 🙂

Dans ce cas, la commande recommandée reste bien :

openclaw update

Évite de l’interrompre tant qu’il y a encore du texte qui défile.
Par contre, si ça reste figé trop longtemps, envoie :

openclaw --version

et les dernières lignes du terminal, et je te dirai si c’est normal ou planté.

Oui, npm 👍

Du coup, openclaw update reste la bonne commande.
Si ça bloque, colle juste les dernières lignes du terminal + openclaw --version.

[versed cairn]

Ça reste figer sur update via package manager depuis plus de 15 min déjà

[north tree]

Là, oui, ça commence à sentir le blocage.

Si c’est vraiment figé sur update via package manager sans nouvelle ligne, fais un seul Ctrl+C, puis colle-moi :

openclaw --version
openclaw update status
openclaw status --all

et si possible aussi les 5 à 10 dernières lignes du terminal.

Comme ça je pourrai te dire si :

• l’update a planté,
• npm attend quelque chose,
• ou si OpenClaw est déjà à jour.

Docs :

• https://docs.openclaw.ai/cli/update
• https://docs.openclaw.ai/help/faq
• https://docs.openclaw.ai/gateway/troubleshooting

[versed cairn]

Je te donne la réponse juste de —version ?

[north tree]

Oui, envoie déjà openclaw --version 👍

Et si tu peux, ajoute aussi les dernières lignes du terminal, c’est encore mieux.
(Petit détail, c’est bien --version avec deux tirets.)

[versed cairn]

Bah ça me dis la dernière version alors que ça a pas fini de se télécharger

[north tree]

Ah, ça c’est déjà un bon indice.

Si openclaw --version affiche déjà la nouvelle version, alors le téléchargement / install a probablement réussi, et ce qui bloque est sans doute après , par exemple sur doctor ou le redémarrage du gateway.

Envoie-moi juste :

openclaw --version
openclaw gateway status

et aussi les dernières lignes du terminal.

Avec ça, je pourrai te dire si c’est fini mais bloqué à la fin, ou vraiment cassé.

[versed cairn]

Putain je sais pas pourquoi ça marchais super bien j’étais sur glm 5.1 cloud par défaut la sur ma Dashboard ça met qwen 3.5 et ca veux pas me répondre même que je met glm 5.1 sur la Dashboard l’agent me répond nul part et ya eu ce problème de mise à jour j’ai fais openclaw update et openclaw —version et la open claw gateway status ca m’a mis ça :

Service: LaunchAgent (loaded)
File logs: /tmp/openclaw/openclaw-2026-04-19.log
Command: /opt/homebrew/opt/node/bin/node /opt/homebrew/lib/node_modules/openclaw/dist/index.js gateway --port 18789
Service file: ~/Library/LaunchAgents/ai.openclaw.gateway.plist
Service env: OPENCLAW_GATEWAY_PORT=18789

Config (cli): ~/.openclaw/openclaw.json
Config (service): ~/.openclaw/openclaw.json

Gateway: bind=loopback (127.0.0.1), port=18789 (service args)
Probe target: ws://127.0.0.1:18789
Dashboard: http://127.0.0.1:18789/
Probe note: Loopback-only gateway; only local clients can connect.

Runtime: running (pid 38884, state active)
RPC probe: ok

Listening: 127.0.0.1:18789
Troubles: run openclaw status
Troubleshooting: https://docs.openclaw.ai/troubleshooting

de plus quand je lui parle sur la Dashboard je vois mon ordinateur travailler dans mon moniteur d’activité mais aucune réponse

[north tree]

Ok, bonne nouvelle, ton gateway a l’air sain.
Runtime: running + RPC probe: ok, donc le souci n’est probablement pas le gateway lui-même.

Le plus probable là, c’est plutôt :

• un souci de modèle / auth,
• ou un override de session dans le Dashboard.

Petit détail utile, le modèle affiché dans le Dashboard est persistant par session. Donc voir qwen 3.5 là-haut ne veut pas forcément dire que ton défaut global a changé.

Fais ce test, dans cet ordre :

openclaw status
openclaw models status
openclaw logs --follow

Ensuite :

1. laisse openclaw logs --follow tourner,
2. envoie un simple test dans le Dashboard,
3. colle ici les lignes qui s’affichent dans le terminal juste après.

C’est le moyen le plus rapide de voir si c’est :

• modèle non autorisé,
• auth manquante / expirée,
• ou un autre blocage.

Docs :

• https://docs.openclaw.ai/help/troubleshooting
• https://docs.openclaw.ai/concepts/models

[versed cairn]

Déjà j’ai taper openclaw doctor ça m’a mis ça :

• channels.telegram: Telegram is in first-time setup mode. DMs use allowlist mode, so │
  │ only sender IDs in channels.telegram.allowFrom are accepted. Group messages stay │
  │ blocked until you add allowed chats under channels.telegram.groups (and optional │
  │ sender IDs under channels.telegram.groupAllowFrom), or set │
  │ channels.telegram.groupPolicy to "open" if you want broad group access. │
  │ │
  ├─────────────────────────────────────────────────────────────────────────────────────────╯
  │
  ◆ Archive 2 orphan transcript files in ~/.openclaw/agents/main/sessions? This only renames them to
  │ *.deleted.<timestamp>.
  │ ○ Yes / ● No
  └

Ça a un rapport ?

[north tree]

Non, pas vraiment.

Les 2 trucs que tu vois sont plutôt annexes :

• le bloc Telegram concerne Telegram uniquement, pas le Dashboard
• Archive 2 orphan transcript files = juste du ménage dans les sessions, pas la cause du “ça réfléchit mais ne répond pas”

Donc pour ton problème actuel, ce n’est probablement pas ça.

Tu peux même mettre No pour l’instant, histoire de ne pas mélanger les sujets.

Le vrai truc utile maintenant, c’est :

openclaw models status
openclaw logs --follow

Puis tu envoies test dans le Dashboard et tu me colles ce que les logs affichent juste après.

Docs : https://docs.openclaw.ai/help/troubleshooting

[versed cairn]

Résultat de openclaw models status :

Config : ~/.openclaw/openclaw.json
Agent dir : ~/.openclaw/agents/main/agent
Default : ollama/glm-5.1:cloud
Fallbacks (0) : -
Image model : -
Image fallbacks (0): -
Aliases (0) : -
Configured models (0): all

Auth overview
Auth store : ~/.openclaw/agents/main/agent/auth-profiles.json
Shell env : off
Providers w/ OAuth/tokens (1): anthropic (1)

• anthropic effective=profiles:~/.openclaw/agents/main/agent/auth-profiles.json | profiles=2 (oauth=0, token=1, api_key=1) | anthropic:default=sk-ant-a...2r8NngAA, anthropic:gab=token:sk-ant-o...j7S7EgAA
• fal effective=profiles:~/.openclaw/agents/main/agent/auth-profiles.json | profiles=1 (oauth=0, token=0, api_key=1) | fal:default=f4c94f51...179fc6b4
• google effective=profiles:~/.openclaw/agents/main/agent/auth-profiles.json | profiles=1 (oauth=0, token=0, api_key=1) | google:default=AIzaSyCA...lZqwq2qk
• ollama effective=profiles:~/.openclaw/agents/main/agent/auth-profiles.json | profiles=1 (oauth=0, token=0, api_key=1) | ollama:default=marker(ollama-local) | models.json=marker(ollama-local) | source=models.json: ~/.openclaw/agents/main/agent/models.json
• openai effective=profiles:~/.openclaw/agents/main/agent/auth-profiles.json | profiles=1 (oauth=0, token=0, api_key=1) | openai:default=sk-proj-...P6tbNyoA

OAuth/token status

• anthropic
  • anthropic:gab static

Et les nouvelle ligne de logs —follow dans le terminal

info gateway/ws {"subsystem":"gateway/ws"} ⇄ res ✓ logs.tail 67ms conn=94b839ee…cd09 id=8855ecdd…ac7d
gateway connect failed: Error: gateway closed (1000):
Gateway not reachable. Is it running and accessible?
Gateway target: ws://127.0.0.1:18789
Source: local loopback
Config: /Users/agentoc/.openclaw/openclaw.json
Bind: loopback
Hint: run openclaw doctor.

[north tree]

Ok, là on a un indice plus clair.

Cette ligne :

gateway closed (1000)
Gateway not reachable

ça ressemble à un gateway qui se ferme / redémarre / décroche, donc pas juste un problème de modèle.
Ça expliquerait pourquoi le Dashboard “travaille” mais ne renvoie rien.

Fais ça maintenant :

openclaw gateway restart

openclaw gateway status
openclaw status

Puis :

1. ouvre le Dashboard,
2. envoie test,
3. relance :

openclaw logs --follow

Si ça recasse, colle-moi :

• la sortie de openclaw status
• et les nouvelles lignes de logs --follow

Pour l’instant, le plus suspect, c’est la stabilité du gateway, pas Qwen/GLM.

Docs : https://docs.openclaw.ai/help/troubleshooting

[versed cairn]

openclaw status
Config warnings:\n- plugins.entries.device-pair: plugin disabled (bundled (disabled by default)) but config is present

OpenClaw status
Overview
│ Item │ Value

│ OS │ macos 26.2 (arm64) · node 25.8.1 │
│ Dashboard │ http://127.0.0.1:18789/ │
│ Tailscale │ off │
│ Channel │ stable (default) │
│ Update │ pnpm · npm latest unknown │
│ Gateway │ local · ws://127.0.0.1:18789 (local loopback) · unreachable (timeout) │
│ Gateway service │ LaunchAgent installed · loaded · running (pid 40030, state active) │
│ Node service │ LaunchAgent not installed │
│ Agents │ 1 · no bootstrap files · sessions 3 · default main active 4m ago │
│ Memory │ 12 files · 21 chunks · sources memory · plugin memory-core · vector ready · fts ready · │
│ │ cache on (21) │
│ Plugin compatibility │ none │
│ Probes │ skipped (use --deep) │
│ Events │ none │
│ Tasks │ none │
│ Heartbeat │ 30m (main) │
│ Sessions │ 3 active · default glm-5.1:cloud (203k ctx) · ~/.openclaw/agents/main/sessions/sessions.json │

Security audit
Summary: 0 critical · 2 warn · 1 info
WARN Reverse proxy headers are not trusted
gateway.bind is loopback and gateway.trustedProxies is empty. If you expose the Control UI through a reverse proxy, configure trusted proxies so local-client c…
Fix: Set gateway.trustedProxies to your proxy IPs or keep the Control UI local-only.
WARN Plugin installs include unpinned npm specs
Unpinned plugin install records: - openclaw-web-search (@ollama/openclaw-web-search)
Fix: Pin install specs to exact versions (for example, @scope/pkg@1.2.3) for higher supply-chain stability.
Full report: openclaw security audit
Deep probe: openclaw security audit --deep

Channels

│ Channel │ Enabled │ State │ Detail │

│ telegram │ ON │ OK │ token config (8704…BzXM · len 46) · accounts 1/1 │

Sessions

│ Key │ Kind │ Age │ Model │ Tokens │

│ agent:main:main │ direct │ 4m ago │ qwen3.5 │ unknown/262k (?%) │
│ agent:main:telegram:direct:8535… │ direct │ 32h ago │ glm-5.1:cloud │ 143k/203k (70%) │
│ agent:main:telegram:slash:85353… │ direct │ 8d ago │ glm-5.1:cloud │ unknown/203k (?%) │
└───────

FAQ: https://docs.openclaw.ai/faq
Troubleshooting: https://docs.openclaw.ai/troubleshooting
Next steps:
Need to share? openclaw status --all
Need to debug live? openclaw logs --follow
Fix reachability first: openclaw gateway probe

[north tree]

Merci, là on voit enfin quelque chose de clair.

Ce que ton openclaw status montre :

1. Ton défaut n’a pas changé
   il est toujours sur glm-5.1:cloud

2. Le Dashboard est sur une session différente, forcée sur qwen3.5
   c’est la ligne :

   agent:main:main ... Model qwen3.5
   

   Donc oui, le qwen que tu vois en haut du Dashboard vient très probablement d’un override de session, pas d’un changement global.

3. Le vrai problème prioritaire, c’est ça :

   Gateway ... unreachable (timeout)

Donc avant même de régler GLM/Qwen, il faut confirmer si le gateway répond vraiment.

Fais juste cette commande maintenant :

openclaw gateway probe

Et colle-moi le résultat.

Si le probe timeout aussi, on sait que le problème principal est bien le gateway qui ne répond pas correctement.
Si le probe passe, alors on attaquera le session override qwen3.5 du Dashboard.

Docs : https://docs.openclaw.ai/help/troubleshooting

[versed cairn]

Ça me met ça quand je met gateway probe

Gateway Status
Reachable: yes
Probe budget: 3000ms

Discovery (this machine)
Found 1 gateway(s) via Bonjour (local.)

Targets
Local loopback ws://127.0.0.1:18789
Connect: ok (72ms) · RPC: ok
Gateway: MacBook-Air-de-Gabriel.local (192.0.0.2) · macos 26.2 · app 2026.4.14
Wide-area discovery: unknown

[north tree]

Parfait, donc le gateway répond bien.
Ça élimine le gros souci de connectivité.

Le point le plus suspect maintenant, c’est ça :

• défaut global : ollama/glm-5.1:cloud
• session Dashboard actuelle (agent:main:main) : qwen3.5

Donc ton Dashboard est très probablement bloqué sur un override de session.

Dans le Dashboard, envoie exactement :

/model ollama/glm-5.1:cloud

Puis juste après :

test

Si tu veux vérifier avant, tu peux faire :

/model status

Je ne vois pas de provider Qwen clair dans ce que tu as collé, donc cette session en qwen3.5 me paraît franchement suspecte.

Si après ça il ne répond toujours pas, relance :

openclaw logs --follow

puis renvoie test dans le Dashboard et colle les nouvelles lignes.

Docs :

• https://docs.openclaw.ai/concepts/models
• https://docs.openclaw.ai/web/control-ui

[versed cairn]

Bah oui c’est bizarre déjà quand je fais /model ollama/glm-5.1:cloud dans mon Dashboard le message disparaît quand je l’envoi et quand je fais test ça bug donc je stop le message et à côté de Assistant j’ai qwen3.5:lasted alors que en haut je suis bien sûr glm-5.1:cloud

[north tree]

Oui, là je pense que ta session Dashboard actuelle est juste foirée / bloquée.

Le plus simple maintenant, c’est de jeter cette session et repartir proprement, sans supprimer l’historique :

1. dans le Dashboard, envoie :

/stop

2. puis :

/new

(ou /reset, c’est ok aussi)

3. ensuite remets explicitement le modèle :

/model ollama/glm-5.1:cloud

4. puis envoie juste :

test

Pourquoi je te fais faire ça :

• ton gateway probe est OK
• ton défaut global est bien glm-5.1:cloud
• mais ta session agent:main:main reste collée sur qwen3.5

Donc le plus probable, c’est un override ou un état de session coincé.

Docs :

• https://docs.openclaw.ai/help/faq#how-do-i-start-a-fresh-conversation
• https://docs.openclaw.ai/concepts/models

Si même après /new ça reste sur qwen3.5:lasted, dis-le moi, et là on regardera le panneau Sessions du Dashboard.

[versed cairn]

Ça c’est les logs follow annalyse les bien

18:40:56+00:00 warn telegram/network {"subsystem":"telegram/network"} fetch fallback: enabling sticky IPv4-only dispatcher (codes=UND_ERR_CONNECT_TIMEOUT)
18:41:01+00:00 error gateway/channels/telegram {"subsystem":"gateway/channels/telegram"} telegram deleteWebhook failed: Network request for 'deleteWebhook' failed!
18:41:01+00:00 error gateway/channels/telegram {"subsystem":"gateway/channels/telegram"} Telegram webhook cleanup failed: Network request for 'deleteWebhook' failed!; retrying in 30s.
18:41:29+00:00 warn agent/embedded {"subsystem":"agent/embedded"} {"event":"embedded_run_agent_end","tags":["error_handling","lifecycle","agent_end","assistant_error"],"runId":"56559e60-f228-41b9-bfe8-751d08252ecc","isError":true,"error":"LLM request timed out.","failoverReason":"timeout","model":"glm-5.1:cloud","provider":"ollama","rawErrorPreview":"502 {"error":"Post \"https://ollama.com:443/api/chat?ts=1776624059\\\": dial tcp [64:ff9b::2224:850f]:443: i/o timeout"}","rawErrorHash":"sha256:46beab37efdb","providerRuntimeFailureKind":"timeout"} embedded run agent end
18:41:41+00:00 warn telegram/network {"subsystem":"telegram/network"} fetch fallback: enabling sticky IPv4-only dispatcher (codes=UND_ERR_CONNECT_TIMEOUT)
18:41:46+00:00 error gateway/channels/telegram {"subsystem":"gateway/channels/telegram"} telegram deleteWebhook failed: Network request for 'deleteWebhook' failed!
18:41:46+00:00 error gateway/channels/telegram {"subsystem":"gateway/channels/telegram"} Telegram webhook cleanup failed: Network request for 'deleteWebhook' failed!; retrying in 30s.

[north tree]

Oui, là les logs sont très clairs.

Ce qu’ils disent vraiment

Le run échoue ici :

"error":"LLM request timed out."
"model":"glm-5.1:cloud"
"provider":"ollama"
"rawErrorPreview":"... Post \"https://ollama.com:443/api/chat ... i/o timeout\""

Donc :

• OpenClaw essaie bien de lancer glm-5.1:cloud
• via le provider Ollama

• mais ton Mac n’arrive pas à joindre https://ollama.com
• et les erreurs Telegram juste au-dessus montrent aussi des timeouts réseau

Conclusion

Le vrai problème, ce n’est pas surtout le Dashboard.
C’est un problème réseau sortant vers des services externes.

Le qwen3.5:lasted dans l’UI est probablement du bruit de session / d’affichage, parce que le log prouve que la tentative réelle part bien sur GLM et qu’elle meurt en timeout réseau.

Le test utile maintenant

Depuis le terminal, lance :

curl -I https://ollama.com

curl -I https://api.telegram.org

Si ça timeout aussi, c’est confirmé, ton réseau / DNS / VPN / IPv6 fout la merde.

Workaround rapide

En attendant, teste un modèle non-Ollama Cloud avec un provider déjà auth chez toi :

/model list

et prends un modèle d’un provider qui apparaît déjà dans openclaw models status autre que ollama.

Docs :

• https://docs.openclaw.ai/providers/ollama
• https://docs.openclaw.ai/help/troubleshooting

Si tu veux, colle-moi le résultat des 2 curl et je te dirai direct si c’est bien un souci réseau.

[versed cairn]

Et si je supprime qwen 3.5 en arrière plan pour laisser uniquement glm 5.1 et utiliser anthropic en arrière plan car j’ai l’impression que c’est qwen 3.5 qui bloque un peu la

[north tree]

Franchement, je ne supprimerais pas Qwen à l’aveugle.

Les logs ne montrent pas que Qwen bloque.
Ils montrent surtout ça :

• tentative sur glm-5.1:cloud
• via Ollama
• qui finit en timeout réseau vers ollama.com

Donc retirer Qwen ne corrigera probablement pas le vrai bug.

Par contre, oui, en workaround :

tu peux passer sur Anthropic pour continuer à utiliser OpenClaw pendant que le souci réseau Ollama n’est pas réglé.

Le plus propre :

openclaw models list

puis tu choisis un modèle Anthropic disponible, et tu le mets en défaut avec :

openclaw models set anthropic/<modele>

Si tu veux gérer ça dans le Dashboard :

/model list

Ma recommandation

• ne supprime pas Qwen pour l’instant
• bascule temporairement sur Anthropic
• et garde en tête que le vrai souci actuel = timeout réseau Ollama Cloud

Docs :

• https://docs.openclaw.ai/concepts/models
• https://docs.openclaw.ai/concepts/model-failover

Si tu veux, colle-moi le résultat de openclaw models list et je te dis lequel prendre côté Anthropic.

[versed cairn]

C’est marquer failed to connect to ollama.com port 443 after 19049 ms : couldnt connect to server

C’est marquer failed to connect to ollama.com port 443 after 19049 ms : couldnt connect to server

[north tree]

Oui, là c’est confirmé.

Ce n’est pas Qwen qui bloque.
Ce n’est même pas vraiment OpenClaw.

Le problème, c’est simplement que ta machine n’arrive pas à joindre ollama.com:443, donc :

• glm-5.1:cloud via Ollama Cloud ne peut pas marcher
• les erreurs Telegram vont dans le même sens, il y a bien un souci réseau sortant

Donc :

• ne supprime pas Qwen pour cette raison
• bascule temporairement sur Anthropic (ou un autre provider déjà auth)
• et pour réparer, regarde côté :
  • VPN
  • Private Relay
  • DNS / bloqueur

• pare-feu
  • ou teste carrément un autre réseau / partage de connexion

Le test le plus simple :

• essaie sur un autre Wi‑Fi ou en partage 4G
• puis refais :

  curl -I https://ollama.com
  

Si ça répond sur un autre réseau, on a trouvé le coupable.

Docs :

• https://docs.openclaw.ai/providers/ollama
• https://docs.openclaw.ai/help/troubleshooting

[versed cairn]

curl -I https://ollama.com
curl: (7) Failed to connect to ollama.com port 443 after 19049 ms: Couldn't connect to server
agentoc@MacBook-Air-de-Gabriel ~ % curl -I https://ollama.com
HTTP/2 200
content-type: text/html; charset=utf-8
set-cookie: aid=eb41ecd5-6263-47cc-beb7-622ba4311b1f; Path=/; Max-Age=31536000; HttpOnly; Secure; SameSite=Lax
x-build-commit: afbfa6fa5491e668edfcd4fecb856dd57fb875f9
x-build-time: 2026-04-19T09:52:08-07:00
x-frame-options: DENY
x-request-id: a556e078-12ee-4f7b-85e9-e60393fde6f2
date: Sun, 19 Apr 2026 18:58:06 GMT
server: Google Frontend
traceparent: 00-8e171c1f32ccbd792e4f4f22a35c5588-f889350a4830f76f-00
x-cloud-trace-context: 8e171c1f32ccbd792e4f4f22a35c5588/17908903711492601711
via: 1.1 google
alt-svc: h3=":443"; ma=2592000,h3-29=":443"; ma=2592000

agentoc@MacBook-Air-de-Gabriel ~ % curl -I https://api.telegram.org
HTTP/2 302
server: nginx/1.18.0
date: Sun, 19 Apr 2026 19:04:13 GMT
content-type: text/html
content-length: 145
location: https://core.telegram.org/bots
strict-transport-security: max-age=31536000; includeSubDomains; preload
access-control-allow-origin: *
access-control-allow-methods: GET, POST, OPTIONS
access-control-expose-headers: Content-Length,Content-Type,Date,Server,Connection

[north tree]

Ah, intéressant. Là ce n’est pas un blocage total.

Ce que ça montre :

• api.telegram.org répond
• ollama.com a d’abord échoué
• puis ollama.com a répondu juste après

Donc le problème a l’air intermittent / instable, pas totalement cassé.
Ça colle très bien avec les timeouts d’OpenClaw.

Et comme ton log montrait une adresse du style 64:ff9b::..., je suis un peu méfiant sur la route IPv6 / NAT64.

Test rapide

Lance ça :

curl -4 -I https://ollama.com

Si avec -4 ça marche à tous les coups, mais sans -4 ça rate parfois, alors le souci vient très probablement de la route IPv6.

Ce que je ferais

1. workaround immédiat : passe temporairement sur Anthropic ou un autre provider déjà auth
2. test réseau : regarde si curl -4 est stable
3. si oui, essaye aussi :
   • couper VPN
   • couper Private Relay
   • changer de réseau
4. puis redémarre OpenClaw :

openclaw gateway restart

et reteste glm-5.1:cloud

Donc non, à ce stade, je ne pense toujours pas que Qwen soit le vrai problème.

Docs :

• https://docs.openclaw.ai/providers/ollama
• https://docs.openclaw.ai/help/troubleshooting

[versed cairn]

Je tapporte une info supplémentaire j’ai un problème de wifi ce qui fais que depuis aujourd’hui je dois tourner en partage de connexion 5g

[north tree]

Ah, ça explique presque tout.

Un partage de connexion 5G peut très bien donner :

• des timeouts intermittents,
• une route IPv6 / NAT64 bancale,
• exactement le genre d’erreurs que tu as sur ollama.com.

Donc oui, je pense que ton vrai problème vient surtout de là.

Ma reco claire

Tant que tu es en partage 5G :

• évite glm-5.1:cloud via Ollama Cloud
• passe plutôt sur Anthropic ou un autre provider déjà auth
• ou utilise un modèle local si tu en as un

Puis, quand ton vrai Wi‑Fi revient :