Recettes CLI du navigateur automatisé : exemples de commandes

Un lancement de BotBrowser est une ligne de commande Chromium à laquelle on ajoute quelques flags --bot-*. Les flags déterminent quel profil d'empreinte est chargé, comment le trafic est acheminé, quelles valeurs régionales la session indique et comment plusieurs processus du navigateur cohabitent sur une même machine. Les recettes ci-dessous sont des commandes de lancement que vous pouvez copier, avec l'explication de ce que fait chaque flag et une méthode pour les ajouter un par un plutôt que de partir d'une longue commande dont personne ne se souvient.

Chaque recette suppose que vous disposez d'un binaire BotBrowser issu des versions GitHub et d'un fichier de profil dont la version majeure correspond à celle du binaire. Les adresses de proxy, les identifiants, les valeurs de cookies et les chemins de fichiers des exemples sont des valeurs fictives. Remplacez-les par les vôtres et traitez chaque recette comme une configuration de départ à adapter, et non comme une promesse de résultats identiques d'une plateforme, d'une version de profil, d'un proxy ou d'un site cible à l'autre.

TL;DR

Les recettes CLI BotBrowser superposent les flags aux réglages et valeurs par défaut du profil. Utilisez --bot-profile, --proxy-server et --bot-noise-seed pour le profil, la route et une comparaison reproductible ; les flags sans licence n'agissent pas et une recette ne garantit pas la qualité du proxy.

Sommaire

• Choisir la plus petite recette pour votre scénario
• Comment les flags de la CLI et les valeurs du profil interagissent
• Recettes de lancement
• Instances en parallèle
• Vérifier une recette avant de s'y fier
• Niveaux de licence, conflits et limites

Choisir la plus petite recette pour votre scénario

Nommez les entrées requises avant d'ajouter des flags : un lancement minimal nécessite --bot-profile, une session routée ajoute --proxy-server et une comparaison reproductible ajoute --bot-noise-seed. Notez ensemble le major du profil choisi et celui du binaire ; une commande qui omet ces entrées n'est pas une recette comparable.

Partez du scénario, pas de la liste des flags. Si vous avez seulement besoin d'un test local, le lancement minimal suffit. Si la session doit sortir par une route précise, ajoutez la recette du proxy. Si vous avez besoin de valeurs régionales différentes de cette route, ajoutez les remplacements par-dessus. Si plus d'un processus du navigateur tourne sur la même machine, lisez la section sur les instances en parallèle avant de monter en charge. Chaque étape ajoute des flags à la précédente, de sorte que vous pouvez toujours retirer le dernier ajout et revenir à une configuration en laquelle vous avez confiance.

• Test local ou développement : le lancement headless minimal.
• Session acheminée sur un serveur : un proxy, un répertoire de données isolé et un port de débogage.
• Valeurs régionales différentes de l'adresse de sortie : remplacements du fuseau horaire, de la locale, des langues et de la position.
• Plusieurs processus du navigateur sur une machine : répertoires de données séparés, ports séparés et un titre pour chacun.
• Exécutions comparables et reproductibles : graines fixes pour le bruit et la temporisation.
• Préparation de session : cookies, favoris, historique et en-têtes personnalisés.
• Diagnostic : enregistrement Canvas et journalisation de Chromium.

Une commande courte est plus facile à maintenir. Chaque flag ajouté est une chose de plus à revérifier après une mise à jour du profil ou du binaire, alors ne gardez que les flags qui répondent à un besoin que vous savez nommer.

Comment les flags de la CLI et les valeurs du profil interagissent

Un profil contient un ensemble complet de valeurs par défaut. Il peut aussi contenir un bloc configs qui remplace ces valeurs, et la ligne de commande peut remplacer les deux. Selon la documentation de gestion des profils, l'ordre de priorité décroissante est : flags --bot-* de la CLI, puis bloc configs du profil, puis valeurs par défaut du profil.

Cet ordre rend les recettes pratiques. Vous gardez un profil de base et vous faites varier le proxy, la locale, la graine et la fenêtre au lancement, sans modifier le fichier du profil. Une recette devient une courte liste lisible de flags au lieu d'une copie modifiée du profil.

Les commandes existantes qui utilisent l'ancienne graphie --bot-config-* restent prises en charge. Utilisez une seule graphie par option dans une même commande de lancement pour que le résultat reste lisible.

Catégories de flags

Les flags utilisés dans les recettes se répartissent en quelques groupes.

• Les flags principaux (--bot-profile, --bot-profile-dir) choisissent le profil d'empreinte à charger. Toute session BotBrowser commence par l'un d'eux.
• Les flags de proxy (--proxy-server, --proxy-ip) contrôlent l'acheminement. BotBrowser étend le flag Chromium standard --proxy-server pour que les identifiants puissent être intégrés à l'URL.
• Les remplacements de configuration (--bot-timezone, --bot-locale, --bot-languages, --bot-window, --bot-screen, --bot-browser-brand) remplacent des valeurs précises du profil chargé.
• Les bascules de comportement (--bot-always-active, --bot-port-protection, --bot-local-dns) modifient un comportement d'exécution qui n'est pas lié à une seule valeur du profil.
• Les flags de personnalisation (--bot-title, --bot-cookies, --bot-bookmarks, --bot-script, --bot-custom-headers) ajoutent des données propres à la session ou un script de démarrage.

Valeurs régionales issues de l'adresse de sortie

Par défaut, BotBrowser déduit le fuseau horaire, la locale, les langues et la position de l'adresse IP par laquelle la session accède à internet. Avec un proxy, il s'agit de l'adresse de sortie du proxy. Dans la plupart des recettes, vous n'avez pas besoin d'indiquer ces valeurs. Ne les remplacez que lorsque vous voulez une configuration différente de celle que suggère l'adresse, et gardez à l'esprit que ces remplacements dépendent de votre niveau de licence.

Flags Chromium standard

BotBrowser accepte aussi les flags Chromium standard, comme --headless, --user-data-dir, --remote-debugging-port, --window-size et --enable-logging. Leur signification est listée dans la référence des options de ligne de commande de Chromium. Si vous hésitez sur le type de flag que vous avez sous les yeux, le préfixe --bot- est un test rapide, et la référence des flags de la CLI fait autorité pour ceux de BotBrowser.

Quelle couche l'emporte pour chaque réglage

L'ordre de priorité est fixe, mais la question pratique après un lancement en est une autre : quelle valeur la session a-t-elle réellement appliquée ? Le tableau indique la couche gagnante pour cinq réglages et la manière la moins coûteuse de relire le résultat depuis le navigateur plutôt que depuis la commande tapée.

Réglage	Valeur par défaut du profil	Configs du profil	Flag CLI	Relecture dans la session
Route du proxy	Connexion directe ou route enregistrée dans le profil	Une route écrite dans les configs du profil	--proxy-server	Ouvrez une page qui renvoie votre adresse et comparez l'adresse de sortie avec l'hôte du proxy configuré.
User agent	La chaîne capturée avec le profil	Une chaîne écrite dans les configs du profil	--user-agent, ou un flag de marque qui la réécrit	Lisez navigator.userAgent dans la console et comparez-la au flag, pas à la chaîne du profil.
Fuseau horaire	Le fuseau capturé avec le profil	Un fuseau écrit dans les configs du profil	--bot-timezone	Lisez Intl.DateTimeFormat().resolvedOptions().timeZone dans la console.
Locale et langues	La locale et la liste de langues capturées avec le profil	Valeurs écrites dans les configs du profil	--bot-locale et --bot-languages	Lisez navigator.language et navigator.languages dans la console.
Écran et fenêtre	Les dimensions capturées avec le profil	Dimensions écrites dans les configs du profil	--bot-screen et --bot-window	Lisez screen.width et window.devicePixelRatio dans la console.

Une valeur de la dernière colonne différente du flag passé signifie que le flag ne s'est pas appliqué. Les causes courantes sont un nom mal orthographié, un niveau de licence qui ne couvre pas le flag, ou une seconde écriture de la même option plus loin dans la commande.

Des paires de flags qui s'annulent sans avertissement

Certaines combinaisons n'échouent pas. Une entrée l'emporte, l'autre disparaît et la commande paraît toujours correcte.

• --bot-profile à côté de --bot-profile-dir : le répertoire l'emporte et le fichier unique est ignoré, si bien qu'un lancement censé fixer un profil varie en silence d'un démarrage à l'autre.
• --bot-screen ou --bot-window à côté de --window-size : ils décrivent des surfaces différentes, et l'écran annoncé peut rester à la valeur du profil alors que la fenêtre réelle suit le flag Chromium.
• --proxy-ip à côté d'une route qui a changé : la session continue d'annoncer l'adresse tapée, donc une valeur ancienne survit à un changement de fournisseur.
• --bot-timezone à côté de --bot-locale, --bot-languages ou --bot-location : chacun s'applique de son côté, et une combinaison qui contredit l'adresse de sortie est acceptée sans avertissement.
• Un flag de marque à côté d'une chaîne explicite dans --user-agent : les deux peuvent décrire des produits différents et parviennent à la page par des surfaces séparées.
• socks5 à côté de --bot-local-dns : la résolution de noms se fait ailleurs qu'avec socks5h, et la route peut résoudre des noms que le proxy ne voit jamais.

Détectez ces cas depuis le navigateur, pas depuis la commande. Comparez l'adresse de sortie affichée par une page d'écho avec celle qu'annonce la session, lisez navigator.userAgent à côté des valeurs de client hints dans le panneau Réseau, et lisez fuseau, locale et écran dans la console. Si deux de ces valeurs divergent, la ligne de commande est correcte et la session ne l'est pas.

Une recette qui démarre proprement mais annonce la valeur de la machine

Le navigateur démarre, la page se charge et la région revient avec le fuseau et la locale de la machine au lieu de l'adresse de sortie. La commande termine avec un code zéro, donc la seule preuve est la valeur lue par la page. Passez ces vérifications dans l'ordre.

1. Confirmez d'abord la route. Chargez une page d'écho et comparez l'adresse de sortie avec l'hôte du proxy. Sans route opérationnelle, toutes les valeurs régionales dérivent de l'adresse de la machine.
2. Lisez la valeur annoncée par la session, pas celle que vous avez passée, pour savoir laquelle des deux est fausse avant de changer quoi que ce soit.
3. Cherchez un remplacement qui demande la machine exprès. --bot-timezone=real, ou la même valeur stockée dans les configs du profil, rétablit le réglage local.
4. Vérifiez l'orthographe et le niveau de licence de chaque flag régional. Les remplacements de ces recettes sont ENT Tier1, et un flag sans son niveau laisse la valeur dérivée en place.
5. Cherchez dans la commande deux écritures de la même option, par exemple l'ancien nom --bot-config-* à côté du nom actuel.
6. Lancez une fois sans flags régionaux pour voir quelles valeurs viennent de l'adresse de sortie, puis ajoutez un remplacement à la fois et relisez le résultat.

Recettes de lancement

Chaque recette montre la commande, puis explique les flags qui comptent. Le nom de binaire chromium-browser est celui d'Ubuntu. Sous Windows, utilisez chrome.exe ou le chemin complet du binaire extrait, et sous macOS le chemin à l'intérieur du paquet de l'application Chromium. Le nom de fichier .enc des exemples est une valeur fictive pour votre propre profil.

Lancement headless minimal

La plus petite configuration utile :

chromium-browser \
  --bot-profile="profiles/profile.enc" \
  --user-data-dir="$(mktemp -d)" \
  --headless

Cette commande charge le profil et s'exécute en mode headless avec un répertoire de données jetable. Le fuseau horaire, la locale et les langues sont déduits de l'adresse IP utilisée par la machine. Utilisez-la pour les tests locaux et le développement.

Session acheminée avec son propre répertoire de données

Ajoutez un proxy, un répertoire de données propre à cette exécution et un port de débogage :

chromium-browser \
  --bot-profile="profiles/profile.enc" \
  --proxy-server=socks5://user:[email protected]:1080 \
  --user-data-dir="/tmp/bb-session-$(date +%s)" \
  --remote-debugging-port=9222 \
  --headless

Le proxy détermine l'adresse de sortie, et BotBrowser en déduit le fuseau horaire, la locale et les langues. Un --user-data-dir unique garde le stockage et l'état de session indépendants des autres processus. Le port de débogage permet à un framework comme Playwright ou Puppeteer de se connecter au navigateur en cours d'exécution. Chromium lie ce port à la machine locale sauf si vous passez --remote-debugging-address ; conservez donc la valeur par défaut sur les machines partagées.

Adresse de sortie connue

Si vous connaissez déjà l'adresse de sortie publique du proxy, indiquez-la :

chromium-browser \
  --bot-profile="profiles/profile.enc" \
  --proxy-server=socks5://user:[email protected]:1080 \
  --proxy-ip="203.0.113.1" \
  --user-data-dir="$(mktemp -d)" \
  --headless

--proxy-ip évite la recherche d'IP à chaque page, ce qui accélère la navigation. Il accepte une adresse IPv4, une adresse IPv6 ou une paire séparée par une virgule. C'est un flag ENT Tier1 ; confirmez donc votre niveau avant de vous y fier.

Fuseau horaire, locale et position explicites

Utilisez des valeurs régionales explicites lorsque l'adresse de sortie ne décrit pas la région voulue :

chromium-browser \
  --bot-profile="profiles/profile.enc" \
  --proxy-server=socks5://user:[email protected]:1080 \
  --bot-timezone="Europe/Berlin" \
  --bot-locale="de-DE" \
  --bot-languages="de-DE,de,en-US" \
  --bot-location="52.5200,13.4050" \
  --user-data-dir="$(mktemp -d)" \
  --headless

Ces quatre remplacements substituent les valeurs déduites de l'adresse de sortie, et les quatre sont ENT Tier1. Le fuseau horaire doit être un nom IANA comme Europe/Berlin, et non une abréviation comme EST. Gardez cohérents entre eux les langues, la locale, le fuseau horaire et les coordonnées, car un écart entre eux, c'est à vous de le repérer.

Aligner la marque du navigateur

Choisissez la marque que le profil doit indiquer :

chromium-browser \
  --bot-profile="profiles/profile.enc" \
  --bot-browser-brand="edge" \
  --user-data-dir="$(mktemp -d)" \
  --headless

Les valeurs acceptées sont chrome, chromium, edge, brave, opera et webview. Lorsque vous fixez une marque, BotBrowser ajuste la chaîne User-Agent, les en-têtes Client Hints et les valeurs associées pour qu'elles correspondent à cette marque. Le changement de marque exige ENT Tier2, et webview exige ENT Tier3. Choisissez une marque cohérente avec la plateforme et la version du profil chargé.

Cookies, favoris et historique au démarrage

Préparez une session qui démarre avec des données déjà en place :

chromium-browser \
  --bot-profile="profiles/profile.enc" \
  --bot-cookies='[{"url":"https://example.com","name":"session_id","value":"abc123","domain":".example.com"}]' \
  --bot-bookmarks='[{"title":"Dashboard","type":"url","url":"https://example.com/dashboard"}]' \
  --bot-inject-random-history \
  --bot-always-active \
  --user-data-dir="/data/persistent-session" \
  --headless

--bot-cookies charge des cookies initiaux. Chaque objet cookie a besoin d'un champ url, et les cookies qui en sont dépourvus sont ignorés silencieusement. --bot-bookmarks ajoute des favoris. --bot-inject-random-history ajoute un historique de navigation, un petit nombre aléatoire d'entrées par défaut ou un nombre exact si vous passez une valeur. --bot-always-active garde actifs les fenêtres et les onglets lorsqu'ils perdent le focus. Les cookies, l'historique et la bascule d'activité permanente sont des fonctions PRO, et le --user-data-dir persistant conserve le résultat d'une exécution à l'autre.

Charger les cookies depuis un fichier

Pour un ensemble de cookies plus volumineux, lisez-les depuis un fichier JSON :

chromium-browser \
  --bot-profile="profiles/profile.enc" \
  --bot-cookies="@/opt/data/cookies.json" \
  --user-data-dir="$(mktemp -d)" \
  --headless

Le préfixe @ indique à BotBrowser de lire les cookies dans le fichier au lieu d'interpréter la valeur comme du JSON en ligne. Un fichier se relit plus facilement et évite les problèmes de guillemets dans le shell. Traitez-le comme un identifiant : limitez les personnes qui peuvent le lire et gardez-le hors du contrôle de version.

Graines fixes pour des exécutions reproductibles

Fixez les graines lorsque deux exécutions doivent être comparables :

chromium-browser \
  --bot-profile="profiles/profile.enc" \
  --bot-noise-seed=42 \
  --bot-time-seed=42 \
  --bot-time-scale=0.92 \
  --user-data-dir="$(mktemp -d)" \
  --headless

--bot-noise-seed rend reproductible la protection de Canvas, WebGL, WebGPU, du texte, de ClientRect et de l'audio : la même graine donne le même résultat d'une exécution à l'autre, et 0 conserve les valeurs par défaut du profil. --bot-time-seed rend reproductible la politique de temporisation d'exécution, et --bot-time-scale accepte un nombre décimal inférieur à 1.0 pour la politique d'échelle de temps. Les trois sont ENT Tier2. Utilisez des graines fixes lorsque vous comparez deux builds ou deux configurations et que la seule différence doit être le changement que vous avez fait.

Enregistrer les appels Canvas pour le diagnostic

Écrivez les appels Canvas dans un fichier lorsque vous devez voir ce qu'une page a demandé :

chromium-browser \
  --bot-profile="profiles/profile.enc" \
  --bot-canvas-record-file="/tmp/canvas-capture.jsonl" \
  --user-data-dir="$(mktemp -d)" \
  --headless

--bot-canvas-record-file enregistre les appels aux API Canvas 2D, WebGL, WebGL2 et WebGPU dans un fichier JSONL. La variation de bruit est désactivée pendant l'enregistrement, la capture est donc déterministe. C'est un flux de diagnostic, et l'outil CanvasLab décrit dans la documentation peut rejouer le fichier. Laissez-le désactivé pour les exécutions courantes.

Automatisation sans framework avec un script de bot

Exécutez un fichier JavaScript au démarrage sans framework d'automatisation distinct :

chromium-browser \
  --bot-profile="profiles/profile.enc" \
  --bot-script="/opt/scripts/automation.js" \
  --user-data-dir="$(mktemp -d)" \
  --headless

--bot-script exécute le fichier une fois par processus du navigateur juste après le démarrage de BotBrowser ; aucun projet Node.js n'est donc nécessaire. La création d'un nouveau contexte du navigateur ne rejoue pas le script ; un contexte qui a besoin de sa propre logique de démarrage reçoit donc le flag dans ses propres options de lancement. Le guide d'automatisation par script de bot montre ce que ces scripts peuvent faire.

Tailles de fenêtre et d'écran

Fixez ensemble les dimensions indiquées par la session et la taille réelle de la fenêtre :

chromium-browser \
  --bot-profile="profiles/profile.enc" \
  --bot-window="1920x1080" \
  --bot-screen="2560x1440" \
  --window-size=1920,1080 \
  --headless

--bot-window et --bot-screen fixent les dimensions de fenêtre et d'écran indiquées par la session. Ils acceptent des valeurs WxH, profile ou real. --window-size est le flag Chromium standard pour la fenêtre réelle. Les profils de bureau utilisent real par défaut en mode avec fenêtre ; passez donc --bot-window=profile et --bot-screen=profile ensemble si vous voulez les dimensions du profil dans une exécution avec fenêtre.

Points de terminaison WebRTC et DNS local

Contrôlez les points de terminaison WebRTC exposés et l'endroit où les noms sont résolus :

chromium-browser \
  --bot-profile="profiles/profile.enc" \
  --proxy-server=socks5://user:[email protected]:1080 \
  --bot-webrtc-ice="google" \
  --bot-local-dns \
  --headless

--bot-webrtc-ice choisit les points de terminaison STUN et TURN exposés par WebRTC, avec le préréglage google ou une liste custom:stun:...,turn:.... --bot-local-dns résout localement les cibles du proxy au lieu de dépendre du comportement DNS du fournisseur du proxy. Les deux sont ENT Tier1.

En-têtes de requête personnalisés

Ajoutez des en-têtes à chaque requête HTTP sortante :

chromium-browser \
  --bot-profile="profiles/profile.enc" \
  --bot-custom-headers='{"X-Request-Source":"internal-tool","X-Team":"research"}' \
  --headless

--bot-custom-headers prend un objet JSON et ajoute ces en-têtes à toutes les requêtes sortantes. Dans du code de lancement JavaScript, n'entourez pas la valeur de guillemets supplémentaires, car les guillemets simples montrés pour Bash feraient partie de la valeur. Servez-vous-en pour les en-têtes qu'attendent vos propres services, et ne mettez pas de vrais secrets dans une ligne de commande que d'autres utilisateurs de la machine peuvent lire. C'est un flag PRO.

Protection des ports

Gardez les services locaux hors de portée des sondages depuis les pages :

chromium-browser \
  --bot-profile="profiles/profile.enc" \
  --bot-port-protection \
  --headless

--bot-port-protection empêche les pages distantes de détecter quels services tournent sur localhost, en couvrant les ports locaux les plus souvent sondés, comme ceux des serveurs de développement et des outils de bureau à distance. Activez-le sur les machines qui hébergent aussi des services locaux. C'est un flag PRO.

Journalisation de Chromium pour le dépannage

Envoyez la sortie de journalisation de Chromium vers la sortie d'erreur standard :

chromium-browser \
  --bot-profile="profiles/profile.enc" \
  --enable-logging=stderr \
  --headless

--enable-logging=stderr est un flag Chromium standard. Lorsqu'un flag semble sans effet, vérifiez sa graphie, son niveau de licence et l'ordre de priorité avant de lire les journaux. Désactivez la journalisation détaillée pour les exécutions courantes.

Instances en parallèle

Un profil est réutilisable. Il peut démarrer plusieurs processus du navigateur : un fichier de profil n'est donc pas lié à un seul navigateur. Ce qui doit différer d'un processus à l'autre, c'est le stockage et le port de contrôle.

Donnez à chaque processus du navigateur son propre --user-data-dir. Sans répertoires de données séparés, les processus partagent cookies, cache et données du profil, ce qui provoque un comportement imprévisible. Donnez aussi à chaque processus son propre --remote-debugging-port, car deux processus ne peuvent pas écouter sur le même port. Ajoutez --bot-title pour que le titre de la fenêtre ou l'entrée de la barre des tâches indique à quel processus elle correspond.

#!/bin/bash
PROFILES_DIR="profiles/windows-chrome"
BASE_PORT=9222

for i in $(seq 1 3); do
  chromium-browser \
    --bot-profile-dir="${PROFILES_DIR}" \
    --bot-title="Worker ${i}" \
    --user-data-dir="/tmp/bb-worker-${i}" \
    --remote-debugging-port=$((BASE_PORT + i)) \
    --proxy-server=socks5://user:[email protected]:1080 \
    --headless &
done
wait

Avec --bot-profile-dir, chaque démarrage sélectionne un profil aléatoire dans le répertoire. Le flag de répertoire ne peut pas être combiné avec --bot-profile : si les deux sont présents, le répertoire est prioritaire. Utilisez --bot-profile lorsqu'une configuration doit rester fixe et --bot-profile-dir lorsque vous voulez de la variation d'un démarrage à l'autre.

Le nombre de processus qu'une machine peut porter dépend de son processeur, de sa mémoire et des pages que vous chargez ; mesurez donc avec votre propre charge de travail avant de choisir un nombre. La boucle ci-dessus utilise un petit nombre uniquement pour garder l'exemple court.

Pour les serveurs, le guide d'installation d'un serveur headless décrit l'environnement Ubuntu que supposent ces commandes.

Vérifier une recette avant de s'y fier

Après avoir ajusté une recette, confirmez ce que la session indique réellement. Lancez-la, ouvrez une page publique de test d'empreinte et comparez ce que vous voyez avec ce que vous avez réglé : le fuseau horaire et les langues par rapport à l'adresse de sortie ou à vos remplacements, la taille de fenêtre par rapport à --bot-window et la marque du navigateur par rapport au flag.

1. Exécutez la commande deux fois avec les mêmes flags et la même graine, et vérifiez que les valeurs censées rester stables le sont.
2. Exécutez-la une fois avec une autre graine ou un autre profil, et vérifiez que les valeurs censées changer changent bien.
3. Ouvrez la page de test avec puis sans le proxy pour voir quelles valeurs régionales proviennent de l'adresse de sortie.
4. Répétez la vérification après toute mise à jour du binaire, du profil ou des flags.

Les pages de test d'empreinte montrent si une configuration est cohérente avec elle-même sur votre machine. Elles ne prédisent pas comment un site tiers traitera une session, et ne remplacent donc pas un essai de votre propre flux de travail avec les sites et les outils que vous utilisez réellement. Comment vérifier la protection de l'empreinte de votre navigateur décrit une routine de test plus complète.

Symptômes et premières vérifications

La plupart des surprises viennent d'un petit nombre de causes. Vérifiez ceci avant tout le reste :

• Un flag n'a aucun effet : vérifiez la graphie du nom --bot-* et si votre niveau de licence couvre ce flag.
• Le proxy ne fonctionne pas : vérifiez la forme complète de l'URL scheme://user:pass@host:port et testez d'abord le proxy séparément.
• Le fuseau horaire semble faux : passez --bot-timezone avec un nom IANA valide, par exemple America/New_York, et non EST.
• La taille de fenêtre est ignorée dans une exécution avec fenêtre : les profils de bureau utilisent par défaut les dimensions réelles du système ; réglez donc --bot-window=profile et --bot-screen=profile.
• Une valeur JSON ne s'analyse pas : vérifiez les guillemets. Dans CMD sous Windows, utilisez des guillemets doubles pour la chaîne extérieure et échappez les guillemets intérieurs.

Niveaux de licence, conflits et limites

Certains flags exigent un niveau de licence. La référence des flags de la CLI les étiquette (PRO, ENT Tier1, ENT Tier2, etc.), et un flag utilisé sans le niveau requis n'a aucun effet. Dans ces recettes, les remplacements régionaux, --proxy-ip, --bot-webrtc-ice et --bot-local-dns sont ENT Tier1 ; le changement de marque et les flags de graine et de temporisation sont ENT Tier2 ; et les cookies, l'historique, les en-têtes personnalisés et la protection des ports sont PRO. Consultez la référence de votre version avant de bâtir un plan sur un flag, car les étiquettes peuvent changer d'une version à l'autre.

Lorsque deux réglages entrent en conflit, l'ordre décrit plus haut tranche : un flag de la CLI l'emporte sur le bloc configs du profil, et ce bloc l'emporte sur la valeur par défaut du profil. Ne répétez pas la même option deux fois dans une commande, et utilisez une seule graphie par option, pour que la commande reste sans ambiguïté.

Pour revenir aux valeurs par défaut du profil, lancez sans les flags --bot-* que vous avez ajoutés. Conservez les jeux de flags dans un script shell, ou dans un module de configuration partagé qui contient le tableau d'arguments pour Playwright ou Puppeteer, afin qu'une recette soit relue et versionnée comme n'importe quel autre code. Il n'y a pas de limite pratique au nombre de flags, mais chacun est un candidat à vérifier lorsque quelque chose se comporte de façon inattendue.

Les mêmes flags fonctionnent sous Windows, macOS et Linux. Adaptez le nom du binaire et le format des chemins à la plateforme, et utilisez un profil dont la version majeure correspond à celle de votre binaire. Gestion des profils explique comment choisir et organiser les profils.

BotBrowser prend en charge des flags CLI --bot-* au lancement qui ont la priorité la plus haute sur les configs et les valeurs par défaut du profil ; vous pouvez donc garder un profil de base et faire varier proxy, locale, graine et fenêtre par recette sans modifier le fichier du profil. BotBrowser ne peut pas faire fonctionner un flag en dehors de son niveau de licence, ne garantit ni la qualité du proxy ni l'exactitude de l'IP de sortie, et ne remplace pas le test de la configuration obtenue avec votre propre flux de travail cible.

Conclusion pratique

Limitez chaque commande aux exigences nommées, notez les majors du profil et du binaire, puis validez la route dans votre propre flux. La CLI sélectionne les entrées documentées, mais ne prouve pas la qualité de sortie du proxy.

Sources

• Versions de BotBrowser
• Référence des flags de la CLI de BotBrowser
• Options de ligne de commande de Chromium
• Documentation BotBrowser : gestion des profils
• Documentation BotBrowser : recettes CLI