MCP Fetch 2026 : localhost refusé ? Guide de dépannage

Le serveur local répond dans le navigateur, mais MCP Fetch refuse la requête après sa mise à jour.

Diagnostic rapide — c’est le comportement de sécurité attendu si la cible se résout vers une adresse privée, de bouclage ou de métadonnées. Vérifiez d’abord l’adresse finale ; n’activez --allow-private-ip que pour un test maîtrisé, sur une instance dédiée, puis retirez cette option.

Cet article s’adresse aux personnes qui utilisent un agent pour tester une application Web en local, ainsi qu’aux équipes plateforme chargées de valider les accès réseau de serveurs MCP.
Si l’agent doit atteindre une ressource interne durablement, privilégiez un environnement de test isolé plutôt qu’une exception permanente sur le poste de développement.

Dernière mise à jour : 13 octobre 2026. Vérification effectuée à partir de la publication officielle MCP Servers v1.0.0, de la modification Fetch correspondante et du README Fetch.

MCP Fetch 2026 : distinguer un refus réseau d’une panne locale

La publication MCP Servers v1.0.0 répertorie Fetch 2026.10.10 et indique un changement de comportement : par défaut, les destinations qui se résolvent vers des adresses privées, de bouclage ou de métadonnées sont refusées. Elle documente également une option permettant explicitement l’accès aux adresses IP privées. Ces éléments sont confirmés dans la publication et la modification officielles.

La conséquence pratique est importante : un refus ne signifie pas nécessairement que l’application Web est arrêtée, que son port est fermé ou que le nom localhost est incorrect. Il peut simplement indiquer que la cible sort du périmètre réseau autorisé au serveur Fetch. À l’inverse, une réponse accessible depuis le navigateur ne prouve pas que le processus MCP peut atteindre la même adresse : les deux clients peuvent utiliser des chemins réseau, des espaces de noms ou des règles de résolution différents.

Nous séparons donc trois vérifications qui sont souvent confondues :

• Le nom demandé : par exemple, localhost, une adresse numérique ou un nom de développement.
• La destination effective : l’adresse obtenue par résolution, y compris après un changement de nom ou une redirection.
• La capacité du processus : son écoute réseau, ses droits, son environnement d’exécution et, le cas échéant, son proxy.

Cette distinction évite de modifier le serveur Web pour résoudre un refus qui provient en réalité du contrôle d’adresse. Elle évite aussi l’erreur inverse : autoriser des adresses privées avant d’avoir vérifié que le service répond réellement.

Première vérification : classer la destination avant de toucher au serveur

localhost désigne une adresse de bouclage, c’est-à-dire une destination qui revient vers l’environnement réseau local du client. Une adresse de réseau privé, elle, permet de joindre un autre équipement ou service dans un réseau non public. Ces catégories ne sont pas interchangeables : un agent exécuté dans un conteneur ou sur une autre machine peut interpréter « local » autrement que le navigateur ouvert sur le poste de développement.

Pour le réseau IPv4, les plages privées définies par le RFC 1918 sont 10.0.0.0/8, 172.16.0.0/12 et 192.168.0.0/16. Ces préfixes permettent de repérer des adresses privées courantes, mais ils ne constituent pas une liste complète de toutes les adresses spéciales ou non publiques. Pour le bouclage et les autres catégories réservées, consultez le registre spécial IPv4 de l’IANA et son registre IPv6.

La liste des plages et leur statut doivent être vérifiés dans les registres cités plutôt que déduits du seul aspect d’une adresse. Le code de validation des destinations de Fetch permet également d’examiner la logique appliquée par le serveur ; ce contrôle ne transforme toutefois pas son comportement en garantie complète contre tous les risques réseau.

Deux diagnostics qui se ressemblent, mais n’appellent pas la même correction

Une panne d’écoute et un blocage d’adresse peuvent afficher des erreurs similaires dans les journaux de l’agent. La comparaison ci-dessous aide à choisir le prochain contrôle au lieu de modifier plusieurs couches à la fois.

L’évaluation est qualitative, pas un score de performance : un refus explicite apporte un indice plus direct sur le contrôle d’adresse, alors qu’un échec de connexion seul ne permet pas de trancher. Nous évitons de conclure à partir du texte produit par le modèle. Une URL générée par un agent n’est pas une preuve de résolution DNS, de route disponible ni d’état d’écoute ; seuls les journaux et contrôles du client concerné permettent d’établir ces faits.

Deuxième vérification : examiner chaque saut d’une redirection

Une adresse de départ publique ne garantit pas que toute la chaîne reste publique. Un site peut répondre par une redirection vers un autre nom, un chemin interne ou une destination qui, une fois résolue, tombe dans une plage refusée. MCP Fetch doit alors évaluer cette destination successive : l’accès initial réussi n’implique pas que les étapes suivantes soient autorisées.

Pour isoler le saut en cause, consignez la séquence dans l’ordre :

• l’URL initiale et l’hôte demandé ;
• la réponse qui déclenche la redirection ;
• l’hôte et le schéma de l’URL suivante ;
• l’adresse obtenue pour ce nouvel hôte, depuis l’environnement où tourne Fetch ;
• le résultat du contrôle ou de la connexion à cette étape.

Ne publiez pas de secrets d’authentification, de paramètres sensibles ni de contenu privé dans un ticket de diagnostic. Si l’outil d’observation disponible ne montre pas toutes les étapes, comparez prudemment les journaux du serveur et les résultats d’une requête contrôlée ; ne présumez pas que l’outil utilisé depuis le poste suit exactement la même route que le processus MCP.

Le point de décision est concret : si une étape mène à une adresse privée qui n’a aucune raison d’être accessible à l’agent, arrêtez le test et examinez la configuration de la redirection. Si cette adresse est celle d’un service de développement que vous maîtrisez, poursuivez plutôt dans un environnement dédié, après avoir évalué la portée de l’exception. Permettre les adresses privées pour faire disparaître une redirection inattendue masque le symptôme sans corriger sa cause.

Troisième vérification : comparer DNS, proxy et environnement d’exécution

Un nom de domaine n’est pas une adresse fixe dans toutes les situations. La résolution peut différer selon la machine, le conteneur, le réseau ou le moment de la requête. Si un nom censé désigner un service public renvoie parfois une adresse non publique, Fetch peut légitimement le refuser ; le fait qu’une requête antérieure ait fonctionné ne prouve pas que la nouvelle résolution est identique.

Nous vérifions alors les limites de la comparaison, plutôt que de supposer que « le DNS est le même partout » :

1. Relevez l’hôte utilisé par la requête qui échoue, sans vous limiter à l’URL présentée par l’agent.
2. Observez la résolution dans le même environnement d’exécution que le serveur MCP, si cette observation est permise.
3. Comparez-la avec celle du client local, en notant explicitement que les résultats peuvent diverger.
4. Vérifiez si un proxy est configuré et si la résolution du nom se produit côté client, côté proxy ou à une autre étape.
5. Contrôlez si le nom change de destination entre les essais, puis conservez les journaux nécessaires à une comparaison.

Les protections documentées ne doivent pas être extrapolées en garantie générale contre la falsification de résolution DNS ou les particularités de résolution par proxy. La portée dépend du chemin effectivement emprunté et de la validation appliquée à chaque destination. Le README Fetch et les recommandations de sécurité du protocole MCP sont les références à consulter pour comprendre les limites déclarées. Un blocage par défaut réduit certains accès indésirables ; il ne remplace ni l’isolation réseau ni l’examen des destinations.

Liste de contrôle avant de réactiver l’accès privé

Cette liste sert à décider si l’exception est justifiée ou si le problème doit être traité dans l’application ou le réseau.

• [ ] Confirmez que le serveur local fonctionne et qu’il écoute sur l’interface attendue dans l’environnement où s’exécute Fetch.
• [ ] Relevez l’adresse réellement obtenue pour la cible ; ne déduisez pas sa portée de son seul nom.
• [ ] Si la requête redirige, identifiez chaque hôte de destination et la résolution associée.
• [ ] Vérifiez que le service privé est bien sous votre contrôle et qu’il ne contient pas de données sans rapport avec le test.
• [ ] Évaluez si un environnement de développement isolé répond au besoin sans ouvrir l’accès depuis le poste principal.
• [ ] Si l’accès privé reste nécessaire, activez --allow-private-ip seulement sur une instance dédiée et dans un environnement de confiance, conformément à la documentation officielle de Fetch.
• [ ] Après le test, retirez l’option, redémarrez l’instance avec les restrictions par défaut et confirmez que la configuration a bien été restaurée.

Activer l’exception sans en faire une règle permanente

L’option documentée --allow-private-ip autorise l’accès aux adresses IP privées. Elle doit être traitée comme une modification du périmètre réseau du serveur Fetch, et non comme un simple réglage de confort pour une URL précise. Son effet dépend de l’instance qui la reçoit : si plusieurs agents ou tâches partagent cette instance, l’exception peut bénéficier à davantage de requêtes que celle qui a motivé le dépannage. Vérifiez les modalités exactes dans la documentation officielle de Fetch avant de modifier votre commande de lancement.

La procédure la plus prudente consiste à séparer l’instance dédiée au test de celle utilisée pour les tâches ordinaires, à limiter les ressources réseau qu’elle peut joindre, puis à retirer l’option une fois le travail terminé. Si la configuration ne permet pas de distinguer les tâches ou de contrôler les destinations accessibles, ne l’activez pas sur une instance partagée. Préférez un réseau de test dont les ressources sont explicitement prévues pour l’agent, ou ajustez l’architecture de l’application pour exposer un point de test maîtrisé.

Ce choix concerne aussi bien un essai de rendu audio ou vidéo que la validation d’un parcours de conception dans une application Web : ces usages créatifs peuvent nécessiter des ressources locales, mais ils ne justifient pas pour autant d’ouvrir indistinctement tout le réseau privé. Définissez d’abord ce que l’agent doit réellement consulter, séparez les données d’essai des ressources de production, et contrôlez les redirections. Le guide d’aide de zekmac peut servir de point de contact si la préparation d’un environnement de développement vous oblige à distinguer l’accès local de l’accès distant.

En cas de blocage, ne cherchez pas à « réparer » la sécurité en autorisant toutes les adresses privées sans diagnostic. Si le but est seulement de tester une page, le plus petit périmètre reste le plus facile à expliquer, à reproduire et à refermer. Si le test est récurrent et implique plusieurs agents, la configuration devrait être documentée comme une exception d’environnement, avec un responsable et une procédure de retour aux restrictions par défaut.

Questions fréquentes sur MCP Fetch et localhost

Pourquoi MCP Fetch refuse-t-il localhost après la mise à jour ?

La publication Fetch 2026.10.10 documente le refus par défaut des destinations qui se résolvent vers des adresses privées, de bouclage ou de métadonnées. Le serveur local peut donc être fonctionnel, mais inaccessible au regard du nouveau contrôle réseau. Examinez l’adresse finale depuis l’environnement MCP avant de modifier l’écoute du serveur ; un nom tel que localhost n’identifie pas nécessairement le même hôte pour tous les processus.

Comment autoriser un serveur de développement local avec MCP Fetch ?

Vérifiez d’abord que le service est maîtrisé, que l’agent doit réellement y accéder et que les redirections ne mènent pas vers des ressources inattendues. Si l’accès privé est nécessaire, la documentation indique l’option --allow-private-ip. Réservez-la à une instance dédiée à un test de confiance, limitez l’environnement réseau et retirez l’option dès que le test est terminé.

Une redirection depuis une page publique vers une adresse interne sera-t-elle refusée ?

Elle peut l’être si l’adresse de destination se résout vers une catégorie bloquée par Fetch. Il faut donc contrôler l’ensemble de la chaîne, et non seulement l’hôte initial : une requête publique peut franchir une redirection avant d’atteindre une destination privée. Notez les hôtes successifs et leurs résolutions ; si un saut est inattendu, corrigez la redirection plutôt que d’élargir immédiatement les autorisations.

Quels risques crée l’accès aux adresses privées ?

Le processus MCP peut atteindre des services internes accessibles depuis son environnement, alors que ces services n’étaient pas conçus pour recevoir les requêtes de l’agent. La portée dépend du réseau, des routes, du proxy et des droits disponibles ; l’option ne doit donc pas être considérée comme limitée à la seule cible de développement. Isolez le test et vérifiez que la configuration par défaut est restaurée après usage.

Pour les tests récurrents, choisissez un environnement que vous pouvez refermer

Si le poste actuel sert à la fois au développement, à l’accès à des ressources internes et aux tâches d’un agent, une exception privée persistante augmente le nombre de chemins qu’il faut surveiller. Un environnement isolé demande une préparation supplémentaire et peut être moins commode pour accéder aux interfaces physiques locales ; en contrepartie, il sépare mieux les ressources de test des services auxquels le poste a déjà accès. À l’inverse, un test ponctuel sur une machine que vous contrôlez peut justifier une exception temporaire, à condition de la désactiver immédiatement après.

Pour des essais qui exigent un environnement de développement distinct, une machine Mac louée chez zekmac peut éviter d’élargir durablement la configuration réseau du poste principal ; ce choix ne convient toutefois pas à un service nécessitant un accès physique local, ni à une charge soutenue pour laquelle une machine dédiée à long terme serait préférable. Vous pouvez comparer les formules de location zekmac avant de choisir : l’objectif n’est pas de remplacer le diagnostic de Fetch, mais de disposer d’un environnement séparé quand la répétition des tests rend l’exception locale difficile à gouverner.