Dépannage

Commencez par scinder tout problème en deux questions : le trafic parvient-il seulement à Chute (problème d'interception) et Chute parvient-il à le transmettre (problème de transmission) ? La vue du trafic en direct y répond — ouvrez le Tableau de bord (iOS) ou l'onglet Trafic de la fenêtre principale (Mac) et parcourez-le : si rien n'apparaît, Chute ne reçoit pas le trafic ; si des connexions apparaissent mais échouent, Chute ne parvient pas à les transmettre. Ces deux moitiés appellent des correctifs totalement différents.

Cette page traite du « ça ne marche pas ». Si la question est « qu'est-ce que ça fait » — lire des requêtes, conserver des corps, modifier une réponse, simuler une panne —, commencez plutôt par le Débogage réseau.

Rien n'apparaît : problèmes d'interception

Chute iOS

• L'interrupteur refuse de s'activer et la barre Config tremble — aucune configuration n'est sélectionnée. Touchez la barre Config, touchez une configuration pour qu'elle affiche une coche, puis Terminé (« Veuillez d'abord sélectionner une configuration »).
• La boîte de dialogue d'autorisation VPN a été refusée — basculez à nouveau l'interrupteur et approuvez-la. Si le profil VPN est bloqué (l'interrupteur revient immédiatement en arrière), utilisez Réinitialiser la configuration VPN dans les réglages de l'app ; le démarrage suivant recrée le profil et redemande l'autorisation.
• Une autre app VPN est connectée — iOS n'exécute qu'un seul tunnel VPN à la fois. Déconnectez l'autre app (ou désactivez ses règles à la demande, qui peuvent silencieusement reprendre le tunnel).

Chute Mac

• Le proxy système est actif mais une app l'ignore — de nombreux outils (les programmes en terminal en particulier) ne respectent pas le proxy système. Dirigez-les explicitement vers l'écouteur de Chute (Copier la commande d'export shell dans le menu le fait pour les shells), ou utilisez le Mode amélioré, qui capture le trafic au niveau réseau.
• Le proxy système ou le mode amélioré ne s'active pas — tous deux dépendent de l'assistant privilégié de Chute. Sa première installation vous demande de l'autoriser, après que Chute en a expliqué la raison (Chute a besoin d'un assistant) ; sous macOS 13 et ultérieur, il peut aussi devoir être autorisé dans Réglages Système → Général → Ouverture et extensions, ce que Chute signale par Approbation requise ou Autoriser Chute dans les ouvertures de session. L'assistant doit être de la version qu'attend l'app (0.8.6 à ce jour) : un assistant d'une autre version est réinstallé automatiquement, approuvez donc cette invite après une mise à jour de Chute.
• Le mode amélioré ne démarre pas — avec le type PacketTunnel, l'extension réseau doit aussi être approuvée ; consultez le dépannage du mode amélioré pour les chemins exacts dans Réglages Système, le cas « Extension système bloquée » et la réinitialisation d'un VPN obsolète.
• Le trafic vers les adresses du réseau local contourne Chute par conception — vérifiez skip-proxy dans Options diverses avant de conclure que l'interception est défaillante. tun-excluded-routes n'est pas la réponse ici : il n'est lu que par les tunnels de Chute iOS, Chute tvOS et Chute Android, et ne fait rien sous macOS. Pour faire entrer une plage du réseau local dans le mode amélioré sur un Mac, listez-la dans tun-included-routes, que les deux types de mode amélioré respectent.

Des connexions apparaissent mais échouent : problèmes de transmission

• Isolez le chemin. Basculez votre groupe de politiques sur DIRECT : si les pages se chargent en direct mais échouent via le proxy, le problème vient du serveur proxy — mauvais hôte/port/identifiants/chiffrement, ou serveur hors service. Lancez un test de latence sur le groupe ; une politique qui ne réussit jamais le test alors que les autres y parviennent désigne le coupable.
• Ce n'est pas la bonne règle qui correspond. Regardez la règle correspondante d'une connexion défaillante dans la vue du trafic en direct, puis relisez l'ordre d'évaluation des règles : les règles sont évaluées en deux passes, donc pour les requêtes fondées sur un nom d'hôte, une règle non IP située plus loin peut correspondre avant une règle IP située plus haut. no-resolve et le placement de FINAL sont les suspects habituels.
• Les réponses DNS semblent erronées. Vérifiez la section DNS : en DNS chiffré, assurez-vous que le serveur DoH/DoT lui-même est joignable sans le proxy ; purgez le cache DNS après avoir changé de serveur (la ligne Purger le cache DNS du panneau de configuration iOS, flushDNS depuis un script, ou DELETE /api/dns/cache sur l'API de contrôle HTTP).
• Les apps dépendantes d'UDP se comportent mal — confirmez que la politique sélectionnée prend en charge le relais UDP (voir la matrice de capacités dans Serveur proxy) et rappelez-vous que Tailscale ne transmet pas l'ICMP : un ping à travers un nœud de sortie reste donc silencieux.

Le déchiffrement HTTPS ne déchiffre pas

• Le CA doit être installé et approuvé — deux étapes distinctes sur iOS ; la seconde (Réglages → Général → Informations → Réglages des certificats) est celle que tout le monde oublie. Consultez Installer et approuver le certificat CA.
• L'hôte doit figurer dans la liste hostname de [MITM] — seuls les hôtes déclarés sont déchiffrés, et uniquement sur le port 443 sauf si un suffixe :port/:0 en décide autrement.
• Certaines apps épinglent leurs certificats et échoueront une fois déchiffrées — excluez leurs hôtes avec un préfixe - plutôt que de lutter contre elles.
• QUIC/HTTP-3 ne peut pas être déchiffré — consultez block-quic pour ramener les clients compatibles vers TCP.
• Sur iPhone, Apple TV et Android, le déchiffrement est une fonction sous licence : sans licence, rien n'est déchiffré, quoi que demandent la configuration ou l'API de contrôle — voir Licence et activation. Sur iPhone, l'interrupteur est la ligne MitM du panneau de configuration. L'Apple TV n'a aucune ligne MitM : là, le déchiffrement s'active par enable = true sous [MITM] dans le profil, ou à l'exécution depuis la Console web, depuis Chute Dashboard, ou avec PUT /api/features/mitm.

Lire les journaux

Lorsque les sections ci-dessus ne suffisent pas, le journal, lui, tranche généralement :

• Élevez temporairement le niveau de journalisation : loglevel = verbose (revenez en arrière ensuite — le mode détaillé est lent).
• Chute Mac : l'onglet Journal de la fenêtre principale. Chute iOS : l'écran du journal de session ; le bouton de partage de la barre de navigation remet tous les fragments de l'exécution. Chute tvOS : l'écran du journal de session, avec au-dessus un filtre de gravité (Tout / Notification+ / Avertissement+ / Critique), de sorte que la télécommande suffit à restreindre. Chute Android : le journal du moteur n'y est pas écrit dans un fichier — lisez-le sur la page Journal de la console (point suivant), emportez-le dans l'Ensemble de diagnostic d'exécution, ou suivez-le avec adb logcat. L'onglet Journaux du tableau de bord et l'onglet Journal d'une session dans la liste des sessions n'affichent que le journal de service propre à l'application (démarrages, arrêts, changements de réseau), que Nettoyer les journaux locaux dans les réglages vide.
• Sur toute plateforme : la page Journal de la console, ou GET /api/logs via l'API de contrôle HTTP.
• Les avertissements sont les lignes intéressantes : politiques inconnues, options rejetées et règles non analysables sont toutes consignées comme avertissements au chargement de la configuration.
• Le journal est découpé en fragments de quelques mégaoctets. Chute conserve les plus récents d'une exécution, si bien que le fichier le plus récent est la fin de l'histoire et non l'histoire entière — emportez-les tous. (Chute Android ne fragmente pas : le journal du moteur lui-même reste dans un anneau en mémoire, et l'application ajoute son journal de service à un unique logs/runtime.log, plus une copie par exécution sous sessions/<run id>/, les deux dans son stockage privé.)
• Sur macOS, les fichiers eux-mêmes se trouvent sous ~/Chute/Share/<run id>/ — voir Emplacement des fichiers (macOS).

Envoyer un ensemble de diagnostic

Quand quelqu'un d'autre doit regarder, une archive vaut mieux que six fichiers retrouvés dans une feuille de partage et un plantage décrit de mémoire. Les apps distinguent deux sortes : un ensemble de diagnostic d'exécution, construit par le moteur en marche, et un ensemble de diagnostic hors ligne, construit par l'app seule. Dans les deux, mots de passe, jetons, cookies et identifiants dans les URL sont remplacés par <redacted>, et les corps de requête et de réponse n'y sont pas inclus.

Ensemble de diagnostic d'exécution — construit par le moteur en marche : une copie expurgée de la configuration, l'instantané de santé du moteur (y compris la façon dont l'exécution précédente s'est terminée), les événements notables de celle-ci, les règles et politiques chargées, le DNS, le trafic et la fin du journal (sur Android, l'anneau de journal en mémoire du moteur, puisque le moteur lui-même n'écrit aucun fichier). Il faut que le tunnel tourne.

• Chute iOS : panneau de configuration → dernière ligne de la section « PROXY LOCAL », Ensemble de diagnostic d'exécution — toujours présente, grisée tant que le tunnel n'est pas connecté, et sans besoin d'external-http-controller ; un appui construit l'ensemble et ouvre la feuille de partage
• Chute Android : panneau de configuration → Ensemble de diagnostic d'exécution, sous les lignes API HTTP — désactivé tant que le VPN ne tourne pas
• Chute Mac : barre des menus → Enregistrer l'ensemble de diagnostic… — le moteur tourne dans l'app, l'ensemble est donc construit sur place et fonctionne que le moteur tourne ou soit arrêté ; c'est toujours la sorte « exécution », le Mac ne construisant jamais la sorte hors ligne
• Chute tvOS : cet appareil n'a ni feuille de partage ni navigateur de fichiers ; Télécharger l'ensemble de diagnostic dans la console est la seule voie — scannez le QR code affiché par l'application et ouvrez la page Diagnostic sur un appareil depuis lequel vous pouvez envoyer un e-mail
• Sur toute plateforme, depuis la console : le bouton de téléchargement de la page Diagnostic, ou POST /api/diagnostics/bundle

Ensemble de diagnostic hors ligne — construit par l'app sans le moteur, il fonctionne donc quand le tunnel est coupé ou n'a jamais démarré : le rapport d'hôte de l'app (version, appareil, état du VPN, résumé de la configuration et les pages de diagnostic « Réseau / Proxy / Table de routage » en texte), le marqueur de sortie de l'exécution précédente (rapporté comme « running » si le moteur tourne réellement) et les fichiers journaux que l'app peut atteindre.

• Chute iOS : réglages → section « DIAGNOSTIC » → Ensemble de diagnostic hors ligne
• Chute Android : réglages → section « DIAGNOSTIQUER » → Enregistrer l'ensemble de diagnostic hors ligne
• Chute tvOS : réglages → Ensemble de diagnostic hors ligne — l'Apple TV construit l'ensemble et affiche un QR code ; scannez-le avec un téléphone sur le même réseau (ou ouvrez l'adresse affichée sur un ordinateur) pour télécharger le zip — le lien ne fonctionne que tant que cet écran reste ouvert
• Chute Mac : il n'y a pas d'ensemble hors ligne ici, et il n'en faut pas — Enregistrer l'ensemble de diagnostic… dans la barre des menus construit la sorte « exécution » même moteur arrêté, en conservant la dernière sortie, la fin du journal et la configuration, et les fichiers qu'il rassemble sont des fichiers ordinaires que vous pouvez joindre directement : les fragments de journal sous ~/Chute/Share/<run id>/ et le marqueur d'exécution ~/Chute/Share/last-run.json — voir Emplacement des fichiers (macOS)

Sur les plateformes qui construisent les deux, le nom du fichier dit laquelle vous avez : un ensemble d'exécution s'appelle diagnostics-<timestamp>.zip, un ensemble hors ligne diagnostics-offline-<timestamp>.zip ; tous deux contiennent un manifest.json dont le champ kind dit la même chose. Un ensemble enregistré depuis Chute Mac est toujours de la sorte « exécution » : son nom ne porte donc jamais la partie offline-.

Avant d'envoyer quoi que ce soit, la ligne Sortie précédente de la page Diagnostic mérite un coup d'œil : Arrêté pour cause de mémoire (Killed for memory) signifie que le système a repris Chute plutôt que Chute n'ait échoué, et cela change ce qu'il faut chercher.

Pourquoi ma réécriture ne fait-elle rien ?

Une règle de réécriture qui ne correspond jamais n'a aucun symptôme : rien ne se produit, ce qui ressemble exactement à une règle qui a correspondu sans effet visible. La console répond directement : la page Règles liste chaque règle de réécriture et de réponse simulée ayant agi pendant cette exécution, avec son compteur. Le tableau suit jusqu'à 512 règles distinctes ; au-delà, il indique combien d'autres se sont déclenchées sans être suivies (rewrite_hit_dropped_rules dans l'API) et n'est plus alors qu'une vue partielle.

• Une règle absente de cette liste n'a jamais correspondu — tant que le tableau ne signale pas de règles non suivies. Vérifiez votre motif face aux formes d'URL décrites dans Réécriture d'URL ; toutes les familles de réécriture, y compris la Réécriture d'en-tête, recherchent le motif n'importe où dans l'URL.
• Une règle qui a agi sans effet visible est un autre problème : ouvrez la connexion dans la console et lisez les lignes Réécritures appliquées, qui nomment la règle dans ses propres termes.
• Les règles ne voient le trafic HTTPS que si le déchiffrement HTTPS est actif pour cet hôte.