OpenClaw en Russie : Gateway sécurisé et configuration API

Pour la connexion BetterToken, ouvrez les instructions OpenClaw et configurez le provider avec SecretRef. Lancez Gateway au premier plan sur loopback, puis effectuez le premier test dans un workspace séparé et une session neuve, sans channels, community skills ni outils dangereux.

Commencez avec une clé distincte pour la première vérification. Créer un compte BetterToken

Ce qu’exécute OpenClaw

OpenClaw comporte plusieurs couches; un problème sur l’une peut ressembler à un problème sur une autre. Séparez-les avant de régler le système.

Couche	Rôle	À contrôler
Provider API	Envoie une requête au modèle choisi	Base URL, API Key, protocole, Model ID
Gateway	Gère control plane local et connexions client	bind, auth, processus, RPC
Agent workspace	Limite le répertoire de travail de l’agent	chemin, fichiers, permissions d’outils
Session	Conserve contexte et état de conversation	nouvelle session après changement de modèle
Channels	Connecte Telegram, Discord et entrées externes	inutile au premier lancement

Dans ce schéma, BetterToken est uniquement responsable de Provider API. Il ne garantit ni le site OpenClaw, ni l’installateur, les channels, community skills ou services tiers. BetterToken API Endpoint est accessible depuis la Russie sans VPN; cela ne s’applique pas aux téléchargements OpenClaw ni intégrations externes.

Installer OpenClaw sans Gateway permanent

Pour le premier contrôle, utilisez l’installateur officiel avec --no-onboard. L’assistant de configuration ne se lance pas et aucun service permanent n’est créé avant vérification du provider.

macOS, Linux ou WSL2

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

Windows PowerShell

& ([scriptblock]::Create((iwr -useb https://openclaw.ai/install.ps1))) -NoOnboard

Vérifiez la CLI :

openclaw --version

L’installateur officiel vérifie la version Node.js prise en charge et l’installe si nécessaire. Ne retenez pas une vieille version Node indiquée par un guide tiers : les exigences actuelles sont publiées sur la page d’installation OpenClaw.

Configurer le provider BetterToken sans API Key publique

Le fichier OpenClaw principal est ici :

~/.openclaw/openclaw.json

Avant toute édition, créez un workspace séparé :

mkdir -p ~/openclaw-first-check

Au premier lancement, sélectionnez le Model ID actuel du groupe BetterToken GPT. La configuration suivante utilise openai-responses; pour un autre provider, ne devinez pas le protocole à partir du nom du modèle. Vérifiez openai-completions ou une autre option dans la documentation BetterToken actuelle.

{
  "models": {
    "mode": "merge",
    "providers": {
      "bettertoken": {
        "baseUrl": "https://www.bettertoken.ai/v1",
        "apiKey": {
          "source": "env",
          "provider": "default",
          "id": "BETTERTOKEN_API_KEY"
        },
        "api": "openai-responses",
        "models": [
          { "id": "YOUR_MODEL_ID", "name": "YOUR_MODEL_ID" }
        ]
      }
    }
  },
  "agents": {
    "defaults": {
      "workspace": "~/openclaw-first-check",
      "model": { "primary": "bettertoken/YOUR_MODEL_ID" }
    }
  },
  "gateway": { "mode": "local", "bind": "loopback" },
  "tools": {
    "profile": "minimal",
    "deny": ["group:runtime", "exec", "process", "sessions_spawn"],
    "elevated": {"enabled": false}
  }
}

YOUR_MODEL_ID est un espace réservé : remplacez-le par l’ID complet donné par le catalogue ou la fenêtre Setup pour votre Key. Laissez Base URL sans /responses ni /chat/completions.

apiKey utilise OpenClaw SecretRef. La valeur BETTERTOKEN_API_KEY doit être définie dans un environnement protégé lisible par le processus Gateway; la clé elle-même n’est pas écrite dans openclaw.json. OpenClaw prend officiellement en charge SecretRef pour models.providers.*.apiKey.

Cherchez d’éventuels credentials ouverts dans config et anciens fichiers générés :

openclaw secrets audit --check

Si l’audit trouve une valeur en clair, utilisez la migration interactive :

openclaw secrets configure --apply

Ne copiez jamais la clé dans prompt, log, commit ou workspace de l’agent.

Vérifier configuration, Gateway et modèle

1. Vérifier le JSON avant l’exécution

openclaw config validate

La commande valide le schéma actif sans lancer Gateway. S’il y a une erreur, corrigez le champ indiqué, les guillemets ou parenthèses, puis contrôlez à nouveau.

2. Vérifier provider et modèle choisi

openclaw models list --provider bettertoken
openclaw models status

bettertoken/YOUR_MODEL_ID doit apparaître dans la liste et le statut doit l’indiquer comme default résolu. models list est une commande en lecture seule : elle ne prouve pas un appel API réussi, donc une courte requête séparée est nécessaire.

3. Lancer Gateway au premier plan

Dans un terminal séparé, exécutez :

openclaw gateway --force

Laissez le processus ouvert. Dans le premier terminal, vérifiez :

openclaw gateway status --require-rpc
openclaw status

Pour un test local, Gateway doit écouter sur loopback, exiger auth et retourner un probe RPC fonctionnel. Ne passez pas bind à lan, tailnet ou 0.0.0.0 au premier essai.

4. Ouvrir une nouvelle session

openclaw tui --session first-check

Dans la session ouverte, contrôlez d’abord la route réellement utilisée :

/status
/model status

Si un autre modèle est sélectionné, choisissez bettertoken/YOUR_MODEL_ID, démarrez une session propre et répétez les deux contrôles :

/model bettertoken/YOUR_MODEL_ID
/new
/status
/model status

Envoyez une requête minimale sans action sur les fichiers :

Réponds uniquement JSON : {"agent":"openclaw","sum":4}. N'utilise aucun tool et ne modifie aucun fichier.

Le premier lancement est confirmé si :

• TUI retourne un JSON valide;
• /status et /model status dans la session actuelle indiquent bettertoken/YOUR_MODEL_ID;
• une requête avec modèle, statut et consommation Token attendus apparaît dans BetterToken Dashboard;
• le workspace ne présente aucun changement inattendu.

Après vérification, arrêtez Gateway au premier plan avec Ctrl+C. Décidez seulement alors si un service permanent est nécessaire.

5. Installer le service seulement après vérification

Si Gateway doit continuer après fermeture du terminal :

openclaw gateway install
openclaw gateway restart
openclaw gateway status --require-rpc

Utilisez openclaw gateway restart pour redémarrer. Le runbook officiel ne recommande pas de le remplacer par une chaîne stop puis start.

Pourquoi le premier lancement doit avoir des droits minimaux

Gateway est conçu par défaut pour un seul cercle de confiance. Un agent avec outils peut lire et modifier des fichiers, exécuter des commandes et accéder au réseau. L’injection de prompt ne vient pas seulement d’un chat public : une page, document, pièce jointe ou log peut contenir des instructions malveillantes.

Au premier test, conservez tools.profile sur minimal, Gateway sur loopback et les channels non configurés. N’installez pas community skills ou plugins avant d’avoir vérifié leur source et leurs permissions. Avant d’élargir l’accès, exécutez :

openclaw security audit --deep

tools.profile: "minimal" n’est qu’un profil de base et ne prouve pas une isolation complète. L’exemple interdit aussi les tools de runtime/control plane, exec, process et sessions_spawn, et désactive elevated mode. Avant la première session avec tools, vérifiez les overrides globaux et agents.entries.* : ils ne doivent pas réactiver host exec, elevated mode, filesystem write ou runtime tools. Exécutez aussi :

openclaw sandbox explain

Si des tools de fichiers sont nécessaires plus tard, configurez d’abord sandbox et workspace access pour l’agent concerné puis répétez les deux audits.

Si vous connectez un channel plus tard, commencez avec pairing ou allowlist et un session scope distinct. Un Gateway partagé entre utilisateurs qui ne se font pas confiance n’est pas une frontière d’isolation prise en charge.

Pourquoi une ancienne session peut employer l’ancien modèle

Après modification de agents.defaults.model.primary, une édition JSON ne suffit pas pour une conversation déjà ouverte. Vérifiez la config, redémarrez Gateway et créez une nouvelle clé de session :

openclaw config validate
openclaw gateway restart
openclaw tui --session after-model-change

Ainsi, le contrôle n’est pas mélangé à l’ancien contexte. Si la nouvelle session utilise encore un autre provider, faites correspondre agents.defaults.model.primary, models.providers.bettertoken.models et la sortie de openclaw models status.

Erreurs fréquentes

config validate échoue

Contrôlez structure JSON et valeurs api prises en charge. Ne lancez pas Gateway avec une config invalide : considérez les modifications directes de l’éditeur comme non fiables jusqu’à validation réussie.

Gateway ne démarre pas ou le probe RPC échoue

Lancez d’abord openclaw gateway status. EADDRINUSE indique conflit de port ou second processus Gateway. Une erreur auth indique une divergence entre credential Gateway et client. Ne désactivez pas auth et n’ouvrez pas bind vers un réseau externe pour contourner l’erreur.

401, 404 ou erreur de protocole

Pour 401, vérifiez que SecretRef est résolu dans l’environnement Gateway. Pour le groupe GPT, utilisez openai-responses et Base URL https://www.bettertoken.ai/v1. Pour un autre provider, prenez le protocole exact dans Docs; n’ajoutez pas l’endpoint manuellement.

Le modèle est dans JSON mais reste invisible

Comparez l’ID dans models.providers.bettertoken.models à agents.defaults.model.primary, puis exécutez openclaw config validate, openclaw models list --provider bettertoken et openclaw models status.

FAQ

Dois-je connecter Telegram ou Discord tout de suite ?

Non. Confirmez d’abord provider local, Gateway, modèle et nouvelle session. Les channels augmentent la surface d’accès et demandent une règle de pairing ou allowlist séparée.

Puis-je écrire l’API Key directement dans openclaw.json ?

Le clair est techniquement pris en charge, mais pour une exécution sûre utilisez SecretRef. Une clé publique en configuration est accessible à tout processus ou outil Agent qui peut lire le fichier.

Comment tester Gateway sans requête modèle réussie ?

openclaw gateway status --require-rpc contrôle RPC et openclaw models status contrôle permission de modèle et credential. Un test end-to-end complet n’est terminé qu’après une réponse courte dans une nouvelle session et l’apparition de la requête dans BetterToken Dashboard.