Traffic Inspector (Français)

§1 Vue d’ensemble

Ce qui rend Traffic Inspector unique

Fonctionnalité	mitmweb	Charles	Fiddler	OmniRoute Traffic Inspector
Basé sur le Web	✓	✗	✗	✓
Open source	✓	✗	partiel	✓
Conscient des agents (sait si la requête provient d’Antigravity/Copilot/etc.)	✗	✗	✗	✓
Conscient des LLM (analyse le format OpenAI/Anthropic/Gemini, les jetons et le modèle)	✗	✗	✗	✓
Mappage des modèles visible (gemini-3-flash → claude-sonnet-4.7)	✗	✗	✗	✓
Séparation de la latence du proxy et du serveur en amont	partiel	✗	✗	✓
Intégré au routage, au repli et aux coûts d’OmniRoute	✗	✗	✗	✓
Débogage du proxy à l’échelle du système (toute application sur la machine)	✓	✓	✓	✓
Capture d’hôtes personnalisés (redirection DNS par hôte)	✓	✓	✓	✓
Mode de variable d’environnement HTTP_PROXY	✓	✓	✓	✓
Vue des conversations (bulles multi-tours, tool_use/tool_result)	✗	✗	✗	✓
Fusion des flux SSE (reconstruction à partir des événements delta)	✗	✗	✗	✓
Enregistrement de sessions (nommées, exportables au format .har/.jsonl)	✗	✓	✓	✓

Architecture en un paragraphe

Le TrafficBuffer (src/mitm/inspector/buffer.ts) est un tampon circulaire partagé en mémoire (1 000 entrées par défaut, configurable via INSPECTOR_BUFFER_SIZE). Toutes les sources de capture y écrivent via push(). Le tampon classe chaque entrée à l’aide de kindDetector.ts (qui détermine s’il s’agit d’une requête LLM), calcule une contextKey (empreinte SHA-256 de l’invite système) et diffuse les données à tous les abonnés WebSocket via globalTrafficBuffer.subscribe(). Le tableau de bord se connecte via GET /api/tools/traffic-inspector/ws et reçoit un instantané lors de la connexion, suivi d’événements new/update/clear.

---

§2 Modes de capture

Traffic Inspector prend en charge 5 sources de capture simultanées. Chacune peut être activée ou désactivée indépendamment. Le champ source de chaque InterceptedRequest (src/mitm/inspector/types.ts) correspond à l’une des valeurs suivantes : "agent-bridge", "custom-host", "http-proxy", "system-proxy" ou "tproxy".

Mode 1 — AgentBridge (par défaut, toujours actif)

Source : gestionnaires AgentBridge (src/mitm/handlers/base.ts) Mécanisme : chaque appel à intercept() dans MitmHandlerBase appelle hookBufferStart() avant le transfert, puis hookBufferUpdate() à la fin. Aucune configuration supplémentaire : cela fonctionne dès qu’AgentBridge est en cours d’exécution. Portée : les 9 agents d’IDE configurés dans AgentBridge Remarque : champ source dans InterceptedRequest = "agent-bridge"

Mode 2 — Hôtes personnalisés (redirection DNS)

Source : liste d’hôtes définie par l’utilisateur (table inspector_custom_hosts) Mécanisme : l’ajout d’un hôte via l’interface utilisateur ajoute 127.0.0.1 <host> à /etc/hosts (nécessite sudo). Le serveur MITM AgentBridge existant (port 443) génère dynamiquement un certificat SNI pour le nouvel hôte. Portée : toute application utilisant l’hôte ajouté, sans aucune modification de la configuration de l’application Remarque : source = "custom-host"

Exemples de cas d’utilisation :

• Surveiller api.openai.com depuis des scripts Python
• Déboguer my-internal-llm.company.com
• Capturer le trafic d’appareils mobiles sur le même réseau (via l’usurpation ARP — avancé)

Mode 3 — Point d’écoute HTTP_PROXY (port 8080)

Source : applications utilisant les variables d’environnement HTTP_PROXY/HTTPS_PROXY Mécanisme : point d’écoute secondaire sur le port 8080 (src/mitm/inspector/httpProxyServer.ts) agissant comme un proxy HTTP/HTTPS explicite standard. Accepte les tunnels CONNECT (HTTPS) et les requêtes HTTP directes. Portée : toute application qui respecte la variable d’environnement HTTP_PROXY, sans modification DNS ni sudo Remarque : source = "http-proxy"

# Capture rapide pour une seule commande :
HTTPS_PROXY=http://127.0.0.1:8080 curl https://api.openai.com/v1/models

# Capture persistante dans une session shell :
export HTTP_PROXY=http://127.0.0.1:8080
export HTTPS_PROXY=http://127.0.0.1:8080

Limitation TLS : les tunnels HTTPS CONNECT sont capturés uniquement sous forme de métadonnées (hôte, port, durée) — le contenu TLS n’est pas déchiffré par défaut. Activez l’option « Déchiffrer HTTPS en mode proxy » (facultative, nécessite que le certificat AgentBridge soit approuvé) pour inspecter l’intégralité du contenu.

Conflit de port : si le port 8080 est utilisé, AgentBridge renvoie une erreur 409 structurée. Modifiez le port à l’aide de la variable d’environnement INSPECTOR_HTTP_PROXY_PORT.

Mode 4 — Proxy à l’échelle du système (avancé, facultatif)

Source : paramètres de proxy du système d’exploitation (s’applique à toutes les applications de la machine) Mécanisme : utilise les API du système d’exploitation pour rediriger tout le trafic HTTP/HTTPS via le point d’écoute HTTP_PROXY :

• macOS : networksetup -setwebproxy / -setsecurewebproxy
• Linux : gsettings set org.gnome.system.proxy + /etc/environment
• Windows : netsh winhttp set proxy 127.0.0.1:8080 Portée : toutes les applications de la machine qui respectent les paramètres de proxy système Remarque : source = "system-proxy"

Mécanismes de sécurité :

• Minuteur de désactivation automatique (30 min par défaut, configurable via INSPECTOR_SYSTEM_PROXY_GUARD_MINUTES)
• L’état précédent du proxy système est enregistré dans la base de données et restauré lors du rétablissement
• Le tableau de bord affiche l’invite « Rétablissement du proxy système » si l’utilisateur quitte la page alors qu’il est actif
• L’interface utilisateur affiche un badge ⚠ Avancé ainsi qu’une case à cocher de confirmation explicite

Mode 5 — Déchiffrement transparent TPROXY (Linux, root, facultatif)

Source : TPROXY du noyau + routage stratégique (src/mitm/tproxy/) Mécanisme : marque les nouvelles connexions TCP locales sortantes vers un port cible (443 par défaut) dans mangle OUTPUT, une règle ip rule redirige les paquets marqués vers une livraison locale, et la cible TPROXY de mangle PREROUTING les transmet à un point d’écoute transparent (IP_TRANSPARENT) (port 8443 par défaut). Le point d’écoute termine TLS avec un certificat feuille émis à la demande pour chaque nom d’hôte SNI par une autorité de certification dynamique, capture l’échange déchiffré, puis transfère la requête, à nouveau chiffrée, vers la destination d’origine. Portée : hôtes de destination arbitraires sur le port cible — aucune usurpation de /etc/hosts, aucune variable d’environnement HTTP_PROXY, aucune modification du proxy à l’échelle du système. Le processus intercepté ne nécessite aucune modification de configuration, mais doit approuver l’autorité de certification dynamique. Remarque : source = "tproxy"

Prérequis : Linux uniquement (IP_TRANSPARENT est propre à Linux), la capacité CAP_NET_ADMIN (root) et un module complémentaire N-API natif qui doit être compilé avec une chaîne d’outils C (npm run build:native:tproxy). Lorsque ces éléments ne sont pas disponibles, l’option du tableau de bord est désactivée et affiche l’infobulle « Le déchiffrement TPROXY nécessite Linux + root + le module complémentaire natif ». Les règles de pare-feu sont appliquées/rétablies de manière transactionnelle (un plantage ne laisse jamais de règle mangle en place) et sont supprimées au redémarrage. Un mécanisme anti-boucle basé sur SO_MARK empêche le transfert rechiffré du proxy d’être à nouveau intercepté.

Il s’agit d’un sous-système conséquent disposant de son propre guide d’exploitation dédié — consultez docs/security/MITM-TPROXY-DECRYPT.md (git ; non compilé dans /docs) pour obtenir la procédure complète de configuration du pare-feu, le programme d’installation de l’autorité de certification dynamique par SNI et du magasin de confiance, la route locale uniquement, les détails du mécanisme anti-boucle et le schéma de configuration. L’option est pilotée par GET / POST / DELETE /api/tools/agent-bridge/tproxy (remarque : la route se trouve sous le préfixe AgentBridge, et non sous celui de Traffic Inspector).

Comparaison des modes de capture

Mode	Configuration	Sudo ?	Portée	Remarques
1. AgentBridge	Automatique	Une fois (certificat+hosts)	9 agents d’IDE	Activé par défaut
2. Hôtes personnalisés	Saisie pour chaque hôte	Oui (fichier hosts)	Toute application utilisant cet hôte	Conservé dans la base de données
3. HTTP_PROXY	export HTTPS_PROXY=...	Non	Applications respectant les variables d’environnement	Port 8080, aucun déchiffrement TLS par défaut
4. À l’échelle du système	Activation + confirmation	Oui	Toutes les applications de la machine	Désactivation automatique après 30 min
5. Déchiffrement TPROXY	Activation (Linux + module complémentaire natif)	Oui (root + installation de l’autorité de certification)	Tout hôte sur le port cible	Déchiffre des hôtes arbitraires ; désactivé par défaut — voir docs/security/MITM-TPROXY-DECRYPT.md (git ; non compilé dans /docs)

---

§3 Interface utilisateur

3.1 Disposition

┌─ Inspecteur de trafic ──────────────────────────────────────────────────┐
│ ┌─ Barre d’outils des sources de capture ──────────────────────────┐   │
│ │ [✓ AgentBridge]  [✓ Hôtes personnalisés (3)] [○ HTTP_PROXY] [○ Système]│
│ └─────────────────────────────────────────────────────────────────────┘  │
│ ┌─ Barre de filtrage/commande ─────────────────────────────────────┐   │
│ │ Profil : (●) LLM uniquement  (○) Personnalisé  (○) Tout          │   │
│ │ [⎉ Pause] [🗑 Effacer] [⬇ .har] [● ENREG. session] ● direct 482/1k│   │
│ └─────────────────────────────────────────────────────────────────────┘  │
├══◀▶══════════════════════════════╬══════════════════════════════════════╤╡
│ LISTE DES REQUÊTES (redimensionnable)║ VOLET DE DÉTAIL                 ▲ │
│ ────────────────────────────── │ ║ [Conversation][En-têtes][Requête]   │ │
│ ▎ 14:32 POST 200 12k AG openai ║ [Réponse][Chronologie][LLM][Stats]  │ │
│ ▎ 14:31 POST 200 8k  CP openai ║                                     ▼ │
│ ▎ 14:31 POST 503 ⚠   KR ...   ║                                       │
│ ▎ 14:30 GET  200 3k  🌐 personnalisé║                                  │
└══════════════════════════════════╝══════════════════════════════════════╝

3.2 Liste des requêtes (volet de gauche)

• Virtualisée (useVirtualList + ResizeObserver) : gère 1 000 éléments sans blocage
• Défilement automatique avec une option permettant de le suspendre pendant l’inspection
• Statut avec code couleur : vert (2xx), jaune (3xx), rouge (4xx/5xx), gris (en cours)
• Emoji de l’agent : 🔵 Antigravity, 🟢 Copilot, 🟠 Kiro, 🟣 Codex, 🔷 Cursor, 🟤 Zed, 🟡 Claude Code, ⚫ Open Code, 🌐 hôte personnalisé
• Barre de couleur du contexte : bordure gauche de 1 px colorée selon contextKey (SHA-256 du prompt système) — regroupe visuellement les conversations associées
• Corps chargé à la demande : seul le corps de la requête sélectionnée est matérialisé dans les onglets de détail (évite d’afficher 1 000 corps de 1 Mo chacun)

3.3 Volet de détail — 7 onglets

Onglet	Contenu	Remarques
Conversation	Bulles de discussion multi-tours (système/utilisateur/assistant + tool_use/tool_result)	Normalisées depuis n’importe quel format de fournisseur ; affichées uniquement si detectedKind === "llm"
En-têtes	Tableaux des en-têtes de requête et de réponse	Les en-têtes sensibles (Authorization, Cookie, api-key) sont masqués par défaut ; option « Afficher les secrets »
Requête	Corps brut, vue arborescente JSON, badge du champ de modèle	JSON mis en forme ou texte brut
Réponse	Corps brut ou liste d’événements SSE ; option « Brut ↔ Fusionné »	Le fusionneur SSE reconstruit le message final à partir des événements delta
Chronologie	Cascade : surcharge du proxy par rapport à la latence en amont	Durée totale, TTFB et taille
Détails LLM	Fournisseur, modèle, nombre de messages, jetons en entrée/sortie, estimation du coût, cible associée	Affichés uniquement pour les requêtes LLM
Statistiques	Recharts : chronologie de la latence, histogramme des jetons, nuage de points des appels d’outils	Affichées uniquement lorsqu’une session enregistrée est chargée

3.4 Commandes de la barre d’outils

Commande	Action
⎉ Pause	Arrête l’affichage des nouvelles requêtes ; un badge « X nouvelles » s’incrémente
🗑 Effacer	Efface la liste de l’interface utilisateur (le tampon du serveur n’est pas affecté)
⬇ Exporter .har	Télécharge la liste actuellement filtrée sous forme de fichier HAR
● Enregistrer la session	Démarre une session d’enregistrement nommée
Sélecteur de profil	LLM uniquement / Hôtes personnalisés / Tout
Filtre d’hôte	Correspondance de sous-chaîne dans le champ host
Filtre d’agent	Liste déroulante : Tous / par agent
Filtre de statut	Tous / 2xx / 3xx / 4xx / 5xx / erreur
Filtre de source	Tous / agent-bridge / custom-host / http-proxy / system-proxy / tproxy
Filtre Direct	Affiche uniquement les requêtes en cours (ouvertes) — option liveOnly (voir §4.6)

3.5 Volets redimensionnables

• La liste et le volet de détail sont séparés par une poignée de redimensionnement
• Largeur de la liste : min. 280 px, max. 720 px, conservée dans localStorage (inspector.listWidth)
• Réductible en un rail de 48 px (icônes uniquement) ; cliquer sur une ligne du rail pour le développer

---

§4 Fonctionnalités adaptées aux LLM

4.1 Détecteur de type (src/mitm/inspector/kindDetector.ts)

Classe chaque requête comme "llm", "app" ou "unknown" à l’aide de 4 signaux :

1. Registre d’hôtes — environ 18 noms d’hôtes d’API LLM connus (OpenAI, Anthropic, Gemini, Groq, Mistral, Together, Fireworks, Cohere, Perplexity, Hugging Face, OpenRouter, xAI, Moonshot, etc.)
2. Motifs de chemin — /v1/chat/completions, /v1/messages, /generateContent, /v1/responses, etc.
3. Structure du corps — détecte les champs messages[] (OpenAI/Claude), contents[] (Gemini), prompt, input
4. Indices de l’agent utilisateur — codex, claude, gemini, antigravity, kiro, copilot, cursor dans la chaîne UA

Les hôtes personnalisés ajoutés via le Mode 2 héritent leur kind de la saisie du formulaire (valeur par défaut : "custom").

4.2 Fusionneur SSE (src/mitm/inspector/sseMerger.ts)

Implémentation indépendante en salle blanche. L’analyse des événements suit l’algorithme WHATWG des événements envoyés par le serveur, tandis que la reconstruction suit les schémas de streaming publics d’OpenAI, d’Anthropic et de Gemini.

Reconstruit le message final de l’assistant à partir des événements delta SSE bruts :

• Anthropic : accumule les content_block_delta par index ; gère text_delta, input_json_delta (appels d’outils), thinking_delta
• OpenAI : accumule les choix/appels d’outils de Chat Completions et les éléments de sortie de l’API Responses par index
• Gemini : accumule candidates[i].content.parts
• Inconnu : renvoie les événements bruts tels quels

L’onglet Response affiche un bouton de bascule : « Événements bruts ↔ Fusionnés ».

4.3 Normaliseur de conversation (src/mitm/inspector/conversationNormalizer.ts)

Implémentation indépendante en salle blanche. La normalisation est définie par des contrats locaux en boîte noire et par les schémas publics de messages d’OpenAI, d’Anthropic et de Gemini ; aucun code source d’implémentation en amont n’est utilisé.

Convertit les formats de messages d’OpenAI, d’Anthropic et de Gemini en un unique NormalizedConversation avant le rendu :

interface NormalizedConversation {
  request: NormalizedTurn[]; // messages / contents / prompt provenant du corps de la requête
  response: NormalizedTurn[]; // réponse de l’assistant (fusionnée via sseMerger)
  contextKey: string | null; // empreinte SHA-256 du prompt système
}

Types de blocs : text, tool_use, tool_result. L’onglet Conversation utilise cette structure quel que soit le fournisseur.

4.4 Coloration de la clé de contexte (src/mitm/inspector/contextKey.ts)

• Calcule le SHA-256 du prompt système (premier message role:system, ou champ system, ou systemInstruction de Gemini)
• Renvoie un préfixe hexadécimal de 12 caractères ("a3f9c2...")
• Le frontend associe la clé à une couleur HSL déterministe pour la barre de bordure gauche
• Filtre « même contexte » : cliquer sur la puce ctx #a3f ajoute un filtre qui affiche uniquement les requêtes ayant la même empreinte

Cela permet de distinguer visuellement facilement les différentes « personas » ou tâches exécutées au sein d’une même session d’agent.

4.5 Extraction des métadonnées LLM

Pour les requêtes LLM, l’onglet LLM Details extrait :

interface LlmMetadata {
  provider: string | null; // "openai" | "anthropic" | "gemini" | ...
  apiKind: string | null; // "chat.completions" | "messages" | "embeddings" | ...
  model: string | null; // provenant du corps de la requête ou de la réponse
  messages: number; // nombre de tours
  tokensIn: number | null; // usage.prompt_tokens / usage.input_tokens
  tokensOut: number | null; // usage.completion_tokens / usage.output_tokens
  streamed: boolean; // true si la réponse est en SSE
  mappedTo: string | null; // en-tête x-omniroute-mapped
  costEstimateUsd: number | null; // coût estimé d’après la tarification d’OmniRoute
}

4.6 Filtre en direct des requêtes en cours

Le champ status de la requête est de type number | "in-flight" | "error" — une entrée est ajoutée avec la valeur "in-flight" dès le démarrage de la requête, puis mise à jour sur place lorsque la réponse (ou l’erreur) arrive. Le bouton « En direct » de la barre d’outils (liveOnly, clé i18n trafficInspector.liveOnly) limite la liste aux entrées dont le status === "in-flight", ce qui permet de surveiller les connexions ouvertes en temps réel.

Le filtre est un prédicat pur côté client dans src/lib/inspector/matchesTrafficFilter.ts :

if (f.liveOnly && req.status !== "in-flight") return false;

L’état du bouton de bascule réside dans useTrafficFilters (les hooks du tableau de bord de l’inspecteur) et se combine avec les autres filtres (profil, hôte, agent, source, statut, contexte).

4.7 Attribution des processus (Linux)

Sous Linux, chaque requête interceptée peut être attribuée au processus local d’origine. Deux champs facultatifs sont ajoutés à InterceptedRequest :

pid?: number;          // identifiant du processus d’origine (Linux uniquement)
processName?: string;  // nom du processus d’origine (Linux uniquement)

src/mitm/inspector/processAttribution.ts associe le port éphémère du client de la connexion à un PID et à un nom en :

1. Lisant /proc/net/tcp et /proc/net/tcp6 afin de trouver l’inode du socket correspondant au port (parseProcNetTcpForInode, un analyseur pur testable à l’aide de fixtures).
2. Parcourant /proc/<pid>/fd/ à la recherche d’un lien symbolique vers socket:[<inode>].
3. Lisant le nom du processus depuis /proc/<pid>/comm.

Un cache avec un TTL de 1 seconde limite le coût de l’analyse de procfs sous charge. L’attribution est effectuée au mieux — tout échec renvoie null et ne bloque jamais la capture. Sous macOS/Windows, la fonction renvoie null (stub ; la prise en charge de lsof/GetExtendedTcpTable fera l’objet d’un développement ultérieur).

---

§5 Sessions

5.1 Enregistrer une session

1. Cliquez sur « ● Enregistrer la session » dans la barre d’outils → saisissez un nom (facultatif)
2. Le suivi en direct se poursuit normalement ; un indicateur rouge clignotant affiche ◉ ENR · <nom> · 00:42 · 23 reqs
3. Cliquez sur « ⏹ Arrêter » → l’instantané de la session est enregistré dans inspector_sessions + inspector_session_requests

5.2 Afficher une session enregistrée

Le menu déroulant Sessions de la barre d’outils répertorie les sessions enregistrées. Lorsque vous en sélectionnez une :

• Charge l’instantané de la session (état figé)
• Une bannière affiche : Affichage de la session enregistrée "<nom>" — [Retour au direct]
• L’onglet Statistiques devient disponible avec les agrégats Recharts

5.3 Formats d’exportation

Chaque session peut être exportée dans les formats suivants :

Format	Utilisation
HAR (HTTP Archive 1.2)	Compatible avec Chrome DevTools, Charles et Fiddler — importation pour analyse hors ligne
JSONL	Un InterceptedRequest par ligne — compatible avec le format llm-interceptor

Exportez via GET /api/tools/traffic-inspector/sessions/{id}/export.har ou le bouton ⬇ du menu déroulant Sessions.

---

§6 Sécurité

Traffic Inspector affiche tout le trafic HTTPS intercepté, y compris les en-têtes d’autorisation et les corps des requêtes. Les contrôles suivants sont en place :

Contrôle	Détails
LOCAL_ONLY	Toutes les routes et le point de terminaison WebSocket sont accessibles uniquement via l’interface de bouclage (appliqué dans routeGuard.ts avant l’authentification)
Masquage des secrets	Le scanner linéaire maskSecret() masque les identifiants Bearer RFC 6750, les clés préfixées par le fournisseur et les longs jetons opaques avant TrafficBuffer.push()
Limite de taille des corps	Les corps > INSPECTOR_MAX_BODY_KB (1024 Ko par défaut) sont tronqués avec la mention "(tronqué pour des raisons de performances)"
Assainissement des en-têtes	Les noms sont convertis en minuscules ; les en-têtes de cadrage/de saut en saut et d’authentification du proxy sont supprimés ; les cookies sont entièrement masqués ; les valeurs d’identification sont déléguées à maskSecret()
CSP	Une politique stricte de sécurité du contenu est appliquée aux pages de Traffic Inspector afin d’empêcher les attaques XSS via des corps de réponse injectés
Aucune persistance par défaut	Le TrafficBuffer réside en mémoire et est perdu au redémarrage du serveur. Les sessions ne sont conservées que lorsqu’elles sont explicitement enregistrées

Règles strictes appliquées

Règle	Application
#12 sanitizeErrorMessage	Toutes les réponses d’erreur HTTP provenant des routes de Traffic Inspector sont assainies
#15 + #17 isLocalOnlyPath()	/api/tools/traffic-inspector/ est LOCAL_ONLY + SPAWN_CAPABLE (commandes du proxy système)

Limitations connues

• Le mode proxy à l’échelle du système affecte toutes les applications de la machine, y compris les clients VPN et le SSO. Utilisez-le toujours avec le minuteur de désactivation automatique. Ne l’utilisez pas sur des machines partagées.
• HTTPS via tunnel CONNECT : le mode 3 (HTTP_PROXY) capture uniquement les métadonnées du tunnel pour les destinations HTTPS, sauf si l’interception TLS est activée. Ce comportement est intentionnel : une capture transparente sans que le certificat AgentBridge soit approuvé interromprait la vérification TLS pour ces applications.
• Chaînes codées en dur dans certains composants : certains composants de l’interface utilisateur (F7/F8) contiennent un petit nombre de chaînes codées en dur qui ne sont pas encore couvertes par les clés i18n. Elles sont documentées comme limitation connue dans le rapport des lacunes i18n ; elles seront migrées lors d’une passe ultérieure. Les chaînes concernées sont des libellés décoratifs de l’interface utilisateur qui ne nécessitent pas de traduction pour une utilisation fonctionnelle.

---

§7 Dépannage

Déconnexion du WebSocket

Si le suivi en direct affiche « Disconnected » :

1. Vérifiez que le serveur est toujours en cours d’exécution : GET /api/tools/traffic-inspector/capture-modes
2. Rechargez la page — le WebSocket se reconnecte et reçoit un nouvel instantané
3. Si le serveur a été redémarré, le tampon en mémoire a été vidé — les anciennes entrées sont perdues, sauf si une session a été enregistrée

Conflit sur le port 8080

Si le mode HTTP_PROXY ne parvient pas à démarrer :

lsof -i :8080    # trouver le processus

Modifiez le port :

.env

INSPECTOR_HTTP_PROXY_PORT=8888

Proxy système non rétabli

Si OmniRoute plante alors que le mode proxy à l’échelle du système est actif :

macOS :

networksetup -setwebproxystate Wi-Fi off
networksetup -setsecurewebproxystate Wi-Fi off

Linux (GNOME) :

gsettings set org.gnome.system.proxy mode 'none'

Windows :

netsh winhttp reset proxy

Le tableau de bord proposera également l’option « Revert system proxy » lors du prochain chargement s’il détecte que l’état de la base de données indique que le proxy était actif.

Tampon plein

Lorsque le tampon atteint INSPECTOR_BUFFER_SIZE (1000 par défaut), les nouvelles entrées remplacent les plus anciennes. Si des requêtes importantes sont perdues :

• Augmentez INSPECTOR_BUFFER_SIZE (par exemple, 5000) — cela augmente la conservation au prix d’une consommation de mémoire supérieure
• Enregistrez une session pour conserver la période pertinente dans la base de données

---

§8 Référence de l’API

Toutes les routes sont LOCAL_ONLY (boucle locale uniquement) et SPAWN_CAPABLE (commandes de proxy système). Consultez src/server/authz/routeGuard.ts.

Chemin de base : /api/tools/traffic-inspector/

Gestion des requêtes

Méthode	Chemin	Description
GET	/requests	Répertorier les requêtes (filtres : ?profile=llm&host=&agent=&status=&source=&sessionId=)
GET	/requests/{id}	Détails d’une requête
DELETE	/requests	Vider le tampon en mémoire
POST	/requests/{id}/replay	Réexécuter la même requête via le routeur OmniRoute
PUT	/requests/{id}/annotation	Enregistrer ou mettre à jour une note associée à une requête

WebSocket

Méthode	Chemin	Description
GET	/ws	Flux WebSocket en direct. Envoie snapshot à la connexion, puis des événements new/update/clear

Exportation

Méthode	Chemin	Description
GET	/export.har	Exporter la liste filtrée actuelle au format HAR 1.2

Hôtes personnalisés

Méthode	Chemin	Description
GET	/hosts	Répertorier les hôtes personnalisés
POST	/hosts	Ajouter un hôte (modifie automatiquement /etc/hosts)
DELETE	/hosts/{host}	Supprimer un hôte
PATCH	/hosts/{host}	Activer ou désactiver enabled

Modes de capture

Méthode	Chemin	Description
GET	/capture-modes	État des modes AgentBridge / hôtes personnalisés / HTTP_PROXY / proxy système, ainsi que de l’option tls-intercept
POST	/capture-modes/http-proxy	Démarrer/arrêter l’écouteur HTTP_PROXY ({action: "start"|"stop"})
POST	/capture-modes/system-proxy	Appliquer/rétablir le proxy à l’échelle du système ({action: "apply"|"revert"})
POST	/capture-modes/tls-intercept	Activer ou désactiver le déchiffrement du corps HTTPS en mode proxy ({enabled: boolean})

Le déchiffrement TPROXY (mode de capture 5) est piloté par une route distincte sous le préfixe AgentBridge — GET / POST / DELETE /api/tools/agent-bridge/tproxy — et non sous /api/tools/traffic-inspector/. Consultez docs/security/MITM-TPROXY-DECRYPT.md (git ; non compilé dans /docs).

Sessions

Méthode	Chemin	Description
POST	/sessions	Démarrer l’enregistrement ({name?: string})
PATCH	/sessions/{id}	Arrêter ou renommer ({action: "stop"|"rename", name?: string})
GET	/sessions	Répertorier toutes les sessions enregistrées
GET	/sessions/{id}	Instantané de la session (toutes les requêtes)
DELETE	/sessions/{id}	Supprimer la session
GET	/sessions/{id}/export.har	Exporter la session au format HAR 1.2

Ingestion interne (solution de secours D4)

Méthode	Chemin	Description
POST	/internal/ingest	Accepte une requête interceptée provenant du chemin de relais de server.cjs ; nécessite l’en-tête INSPECTOR_INTERNAL_INGEST_TOKEN

Schémas OpenAPI complets : docs/openapi.yaml → étiquette Traffic Inspector.

---

Code source d’OmniRoute (a58000c7685f)