Questions fréquentes

Procédez dans cet ordre : d'abord la version, puis la source de données, enfin les identifiants et le cache. Si un message d'erreur contient des mots de passe, sessions, commandes d'installation Agent ou secrets tiers, ne le collez pas dans un ticket public.

La mise à jour système affiche HTTP 429

Le Worker a rencontré une limite de débit amont en lisant le manifest GitHub Raw officiel ; ce n'est pas une panne Agent. Depuis 1.0.38, les vérifications de mise à jour utilisent un cache de succès de six heures, fusionnent les requêtes concurrentes et appliquent un backoff de 15 minutes après échec. Quand la source officielle est indisponible, le dernier cache réussi est utilisé ; au démarrage à froid, le manifest de confiance embarqué dans le déploiement sert de référence.

• « Utilisation de la version déployée / du résultat en cache » est une dégradation sûre.
• Ne rafraîchissez pas en boucle et n'augmentez pas la fréquence de nouvelle tentative.
• Vérifiez que /api/health, /update-manifest.json et /bin/VERSION indiquent la même version.
• Les mises à jour auto-hébergées passent par le workflow NIE-SLA Online Update du dépôt de déploiement ; aucun champ de Token GitHub n'est nécessaire.

À propos de l'accès *.workers.dev

Les déploiements auto-hébergés peuvent utiliser l'adresse *.workers.dev par défaut — un déploiement en un clic tout neuf n'a généralement pas encore de domaine et c'est son entrée principale. Après avoir lié un domaine personnalisé, si vous ne voulez pas garder ce point d'entrée parallèle (il contournerait vos limites de débit et protections), ajoutez la variable texte ALLOW_WORKERS_DEV = false dans Worker → Settings → Variables and Secrets puis enregistrez ; le site de production officiel désactive en plus la route workers.dev au niveau de la configuration. Vérifiez aussi le chemin : la page publique est / et l'entrée d'administration est votre ADMIN_PATH configuré (pas /admin).

404 après modification du chemin d'administration

Quand ADMIN_PATH est enregistré, l'ancienne entrée cesse de fonctionner immédiatement. Rouvrez « URL du Worker + nouveau chemin ». Le chemin n'est pas une authentification ; la vraie frontière reste le mot de passe, la session courte et le TOTP optionnel.

Agent publié mais la version du nœud n'a pas changé

Les Agents interrogent la politique de mise à jour ; ils ne passent pas tous à la nouvelle version au moment de la création de la release. Vérifiez agent_version, l'état en ligne et le statut Manager dans le panneau, puis sur le nœud :

sudo cftz status
sudo cftz log 100

Les versions très anciennes peuvent manquer du Manager actuel ou de la chaîne de vérification complète ; relancez la dernière commande d'installation générée pour ce nœud. Ne réutilisez pas la commande d'un autre nœud ; son jeton est mono-nœud.

Les nœuds BusyBox échouent NQ/IP avec des erreurs d'arguments setpriv

1.0.49-1.0.50 passait les arguments GNU setpriv --reuid/--regid à BusyBox ; la chute de privilèges directe a ensuite corrigé le démarrage mais a retiré les sondes raw socket, latence et route de NQ, produisant « tâche réussie mais latence tout à 0, trajet retour NoData ». Passez à v1.0.58+ : NQ et le déblocage IP tournent directement sous le Manager root-only, sans nstatus-task, no_new_privs ni user namespaces. La collecte de métriques reste assurée par le service non privilégié nstatus ; le Manager n'accepte que les deux actions fixes et applique SHA-256 du script, répertoires privés, absence de symlinks, PATH fixe, délais et limites de sortie.

v1.0.59 a porté le plafond de la détection profonde NQ de 30 à 60 minutes pour que les disques lents ne sortent pas trop tôt pendant HardwareQuality ; le déblocage IP reste à 10 minutes.

Depuis v1.0.64, les options NQ (HardwareQuality y/f/v/n, IPQuality y/n, NetQuality y/l/n, Trajet retour y/n) se choisissent par tâche dans l'interface, pour les exécutions unitaires et par lots ; les tâches NQ n'ont pas de délai externe et l'expiration de file conserve une grâce de 7 jours.

v1.0.66 a corrigé les NQ par lots tués par exit 124 vers ~600 s sur les anciens Agents : le Worker ré-émet un plafond de compatibilité de 3600 secondes pour les Agents antérieurs à v1.0.64 ; les Agents v1.0.64+ n'ont toujours pas de délai externe.

v1.0.67 a corrigé les dialogues NQ/IP par lots qui ne se fermaient pas après « confirmation de file », les notifications manquantes et certains VPS qui ne démarraient pas : les lots créent désormais les tâches 5 par 5, le frontend ferme le dialogue immédiatement avec un avis de mise en file, et le délai des requêtes par lots est passé à 60 s.

v1.1.0 est passé aux numéros décimaux (1.1.0) : l'aperçu/la restauration des sauvegardes a gagné une limitation basse fréquence D1, et les dépassements de tâches notent désormais « la requête peut encore s'exécuter côté serveur, rafraîchissez plus tard ».

v1.1.1 a ajouté un arrêt forcé pour les tâches NQ/déblocage IP : les tâches en file sont annulées immédiatement et le nouvel Agent termine la tâche en cours comme un groupe de processus entier après détection du drapeau d'annulation ; le tableau et le dialogue de détail affichent un bouton « Arrêter de force » et un état « Arrêt en cours ».

v1.1.2 fait aussi préférer les données de déblocage du rapport NodeQuality dans l'état public et le panneau, afin qu'un rapport NQ entièrement débloqué ne soit plus remplacé par un ancien échec IP.Check.Place ; 中国 s'affiche en rouge et les états bloqué/échec/réservé aux membres apparaissent dans le badge rouge.

v1.1.3 a corrigé les téléchargements des composants NQ sur des réseaux comme Tencent Cloud : le script statique garde la source GitHub officielle, retombe sur des miroirs testés en cas d'échec et applique SHA-256. Le Runner de tâches Agent a gagné l'appartenance d'instance et un heartbeat de secours de 30 minutes, et la route GET /api/agent/tasks dupliquée a été corrigée.

v1.1.4 a ajouté le sélecteur de source d'accélération (auto / EdgeOne Chine / Cloudflare étranger) au dialogue NQ. Le script audité préfère l'accélérateur public NIE-Proxy et retombe sur les sources officielles et miroirs ; la vérification SHA-256 reste inchangée.

v1.1.5 achemine aussi les paquets Geekbench 5 téléchargés par HardwareQuality via l'accélérateur NIE-Proxy sélectionné ; la liste d'autorisation ajoute cdn.geekbench.com.

v1.1.6 a retiré EdgeOne des dialogues NQ, ne laissant que « Défaut » et « Cloudflare étranger » ; les anciennes tâches eo retombent automatiquement sur le défaut.

v1.1.7 fait authentifier l'API de téléversement avant l'analyse du corps. Le test budgétaire statique de l'époque ne couvrait que le trafic de base ; les données de production ont ensuite montré que les sondes, Durable Objects et la durée du scheduler étaient sous-estimés. Il ne garantit donc pas 100 nœuds.

v1.1.8 a corrigé les IDs de cible contenant & : le Worker résout l'ID d'origine, l'ID normalisé et la correspondance scannée pour que metrics, pings, config et location aboutissent à la cible d'origine.

v1.1.9 a corrigé les croisements de graphes lors d'un changement rapide de plage, fait couper les courbes TCP Ping et Latency en cas de perte, et réorganisé la liste des probes admin.

v1.1.10 a ajouté l'interrupteur « Continuité des points » à la barre d'outils des graphiques : Latency et TCP Ping coupent par défaut en cas de perte ou d'échec, et l'option relie les valeurs nulles en la conservant dans le navigateur.

v1.1.11 a restauré la disposition en tableau précédente de la liste des probes admin et supprimé les blocs de surveillance trop larges ; la densité d'information et la zone d'action reviennent à l'état d'avant 1.1.8.

v1.1.12 a réduit la cadence de sondage : timeout unique à 3 s, snapshots d'état toutes les 2 min, latence régionale toutes les 3 min et dégradation automatique à 10 min pour les cibles en échec continu. Les images des rapports NQ utilisent le cache edge, le polling d'annulation des tâches Agent passe d'un délai fixe de 2 s à un backoff de 5-10 s, et le cache agrégé D1 avec de nouveaux index a été livré.

La version v1.1.18 a livré l'expérience à 300 s, la réutilisation WS, le tampon R2 horaire et le support cache/304 ; v1.1.22 a ajouté l'API Ping par lots, afin qu'un panneau public puisse lire l'historique Ping complet des VPS en une seule requête. Le manifest et l'historique de publication du déploiement cible restent la référence.

IPv6 et sondes Cloudflare

« Agent en ligne mais Latence CF en échec » est généralement un problème de sens : le rapport Agent ne prouve que le réseau sortant ; la capacité de Cloudflare à joindre le port de la VPS est un autre chemin. Points clés :

• Saisissez l'IPv6 dans le champ hôte sans [] ; mettez le port dans le champ port.
• L'IPv6 littérale peut être refusée par Cloudflare ; essayez un domaine AAAA en DNS-only pour la même adresse.
• N'activez pas le proxy (orange cloud) : l'AAAA résoudrait vers les adresses de proxy Cloudflare et les TCP Sockets Workers interdisent de se connecter aux IP Cloudflare.
• Depuis une autre IPv6 publique, vérifiez avec nc -6 -vz domaine port.

Le dépannage complet se trouve dans le sujet IPv6 de cette documentation.

Images NQ manquantes ou obsolètes

• Les images Network et Return Route sont rendues et téléversées par le Worker ; en cas d'échec de l'hébergeur, l'interface retombe sur le rapport texte et la tâche n'est pas en échec.
• Les URL d'images publiques sont des proxys même origine ; l'hébergeur amont n'est jamais exposé.
• La chaîne passe par le broker public officiel ; les déploiements ordinaires ne peuvent pas et n'ont pas besoin de configurer leur propre NQ_IMGBED_URL/NQ_IMGBED_TOKEN.
• Seuls les rapports produits après la prise d'effet de la configuration sont traités ; les anciens rapports ne sont pas re-téléversés.

Le nœud de latence externe affiche « pas encore rapporté »

Créer l'enregistrement du nœud n'est pas le déployer. Vérifiez : la dernière commande complète du nœud a tourné sur la bonne machine ; la sortie d'installation contenait accepted ; le service est actif ; les journaux n'ont pas d'erreurs 401/403/TLS/DNS persistantes. Les anciens nœuds doivent être réinstallés avec la commande complète, pas simplement redémarrés.

Erreurs CORS navigateur sur l'API publique

curl fonctionne mais pas le navigateur : l'origine manque dans DEVELOPER_API_ORIGINS. Ajoutez l'origine complète (https://status.example.com), sans chemin ni *. La production doit être en HTTPS ; HTTP n'est que pour le développement local.

Sauvegarde et restauration

• La restauration exige un aperçu préalable et un mot de confirmation ; la fusion et le remplacement sont pris en charge.
• Le Worker conserve un instantané R2 avant restauration ; en cas d'échec, gardez l'instantané et consultez les journaux au lieu de cliquer en boucle.
• Les jetons Agent des sauvegardes sensibles sont re-encapsulés à la restauration, donc les nœuds continuent de s'authentifier après un transfert de compte.
• Les sauvegardes normales ne contiennent aucun jeton ; l'historique haute fréquence n'est pas dans le JSON ; réutilisez le R2 d'origine lors d'une migration.

Affichage de la capacité disque

agent_metrics.vps_info.total_disk_gb est la capacité du système de fichiers racine, pas une somme des montages ; les bind mounts du même périphérique ne sont pas comptés deux fois.

Thèmes et thèmes Canvas

Seuls les paquets de thèmes sont ouverts dans la version actuelle ; il n'y a pas de runtime de plugins. Utilisez un thème CSS pour les couleurs et l'espacement uniquement ; utilisez un thème Canvas pour réécrire entièrement la mise en page, l'interaction ou les graphiques de la page publique. Les thèmes Canvas tournent dans une iframe sandbox sans accès même origine, ne lisent l'état public que via le protocole de messages et ne peuvent pas joindre le réseau ni la page hôte directement.

• Les téléversements démarrent désactivés ; un administrateur vérifie le SHA-256 puis les active manuellement. La désactivation restaure immédiatement l'interface d'origine.
• Ne distribuez pas de ZIP type: "plugin" ; le téléversement de plugins et le protocole de messages de plugins des anciens tutoriels n'ont jamais été ouverts dans la version actuelle.
• Un panneau séparé utilise l'API publique v1, se déploie sur son propre domaine et exige une liste DEVELOPER_API_ORIGINS exacte.

Quota gratuit

Le mode économique utilise par défaut 15 minutes pour les cibles saines et les lots Agent, 10 minutes pour les tâches, une vérification quotidienne des mises à jour ordinaires et environ 2 minutes pour les cibles en panne. Il réduit fortement les requêtes et Unbound pour 100 VPS par rapport à l'ancien modèle de 5 minutes ; les métriques peuvent avoir jusqu'à 15 minutes de retard. Les alertes Dashboard Workers, Durable Objects, D1 et R2 restent nécessaires.

État actuel (1.1.93) : les tampons de télémétrie et l'historique des sondes vivent dans des Durable Objects partagés, et les écritures D1 ne servent plus que de repli. À la cadence réelle de 5 minutes, Workers, Durable Objects, D1 et R2 restent dans le quota gratuit (les lignes lues D1 étant le poste le plus tendu). Utilisez le modèle d'usage et la facture Cloudflare du déploiement cible pour les ratios exacts, au lieu d'extrapoler l'ancien budget statique de 100 nœuds.

Un nœud ne peut pas joindre Cloudflare / Fastly / Akamai

Certains réseaux n'atteignent pas les CDN Cloudflare : installation, remontées et mises à jour automatiques échouent. Utilisez un simple relais TCP sur une machine qui atteint le site (TLS/SNI/Host passent tels quels — aucun domaine, certificat ni CDN requis) :

sudo apt install -y socat
sudo systemd-run --unit=nie-sla-relay socat TCP-LISTEN:443,fork,reuseaddr TCP:sla.niekaixiang.com:443

Limitez le port 443 à l'IP du nœud relayé dans le pare-feu et recréez l'unité après un redémarrage. Puis, sur le nœud restreint, faites pointer les deux domaines officiels vers le relais et lancez la commande d'installation générée :

echo "<ip-relais> sla.niekaixiang.com api-sla.niekaixiang.com" | sudo tee -a /etc/hosts
curl -fsS https://sla.niekaixiang.com/api/health

La validation TLS, l'en-tête Host et l'URL de téléchargement des mises à jour restent le domaine officiel : remontées, tâches, WebSocket et mises à jour passent par le relais. Si seul IPv6 ou un port alternatif répond, essayez d'abord curl -6 -fsS https://<domaine>/api/health ou curl -fsS https://<domaine>:8443/api/health.

L'installateur refuse désormais --token (1.1.65+)

Pour éviter que le jeton apparaisse dans ps et l'historique du shell, setup.sh, install-mac.sh et quick-install.sh rejettent --token et demandent la variable d'environnement ou la saisie interactive :

NIE_SLA_AGENT_TOKEN='...' sudo -E bash setup.sh --non-interactive

Les commandes en un clic générées par le panneau utilisent déjà des variables d'environnement et des identifiants à usage unique.

Les contrôles proxy restent hors ligne ou expirent

Vérifiez d'abord la version de l'Agent exécutant de la cible. Jusqu'à 1.1.53, le correctif de tampon de handshake Reality (1.1.57) manque : les nœuds Reality expirent à exactement 5 secondes avec stage=connect / timeout (handshake et premier octet à -). Mettez le nœud à jour vers v1.1.57+ (relancez la commande de déploiement générée) ou choisissez un autre agent exécutant déjà à jour. Si tous les échantillons échouent encore, revérifiez le lien de partage et les paramètres (clé publique Reality et short ID requis).

Le panneau signale une nouvelle version mais rien ne se met à jour

Les mises à jour en ligne des déploiements en un clic sont exécutées par le workflow NIE-SLA Online Update du dépôt de déploiement sur GitHub Actions, qui vérifie la version stable officielle toutes les 6 heures. Il ne s'exécute pas dans le Worker : le Worker ne peut pas se mettre à jour lui-même, et la carte « Mise à jour » du panneau ne fait qu'afficher les versions.

Si l'onglet Actions affiche « Get started with GitHub Actions » (aucun workflow), le déploiement en un clic n'a pas copié le workflow dans le dépôt. Installez-le une fois depuis le navigateur (la logique de mise à jour reste dans le dépôt officiel, cette étape est unique) :

1. Ouvrez l'onglet Actions du dépôt de déploiement → cliquez sur set up a workflow yourself ;
2. Collez l'extrait ci-dessous puis Commit changes ;
3. Choisissez ensuite NIE-SLA Online Update dans la barre latérale → Run workflow.

name: NIE-SLA Online Update
on:
  workflow_dispatch:
  schedule:
    - cron: "17 */6 * * *"
permissions:
  contents: write
jobs:
  update:
    uses: 3257085208/NIE-SLA/.github/workflows/nie-sla-update.yml@main

Si le déploiement reste sur une ancienne version, vérifiez dans l'ordre :

1. Actions est-il activé ? Dépôt → Settings → Actions → General, autorisez l'exécution des workflows (un dépôt neuf ou dupliqué peut avoir Actions désactivé).
2. Y a-t-il des exécutions ? L'onglet Actions doit montrer des exécutions planifiées « NIE-SLA Online Update ». Aucune exécution : utilisez l'extrait d'installation ci-dessus ; une fois installé, cliquez sur Run workflow pour en lancer une immédiatement.
3. Lisez le journal d'échec (dernière étape de l'exécution en échec) :
   • no online-update baseline : le contenu du dépôt ne correspond pas à la base officielle de sa version ; synchronisez une fois manuellement ;
   • Deployment files differ from the official … baselines : le dépôt contient des modifications hors version officielle (seul wrangler.jsonc peut différer) ;
   • erreurs de dépendances ou de build : relancez une fois depuis la dernière branche.
4. Attendez le build Cloudflare : après le push du workflow, Cloudflare Workers Builds a encore besoin d'environ 1 à 3 minutes ; forcez le rafraîchissement du panneau puis cliquez sur « Vérifier les mises à jour ».

Sans GitHub Actions, mettez à jour manuellement : synchronisez le dépôt sur la dernière version officielle puis exécutez npm run deploy, ou redéployez depuis le dernier modèle en un clic (qui apporte aussi les dernières liaisons Durable Object et le provisionnement du secret interne).