Pourquoi Firefox continue de proxifier un hôte intranet dans votre sous-réseau d'exception
Une plage d'exception pour des adresses IP littérales n'exempte pas forcément un nom d'hôte qui se résout dans cette plage.
Vous avez saisi 192.168.0.0/16 dans la liste « Aucun proxy pour » de Firefox. Ouvrir http://192.168.1.20/ passe en direct, mais http://wiki.office.example/ atteint toujours le proxy. Les deux URL peuvent désigner le même serveur.
La différence importante est la chaîne de destination que Firefox compare. Une exception de plage IP et une exception de nom d'hôte ne sont pas interchangeables. Ne partez pas du principe que la liste d'exception manuelle résout chaque nom d'hôte avant de décider si une règle de plage d'adresses s'applique.
| URL saisie | Informations disponibles pour la comparaison |
|---|---|
| http://192.168.1.20/ | Une adresse IP littérale |
| http://wiki.office.example/ | Un nom d'hôte |
Si l'intranet dispose d'un domaine dédié, utilisez les exceptions de nom d'hôte ou de domaine appropriées plutôt que de deviner les adresses vers lesquelles les noms peuvent se résoudre. Gardez les services publics sans rapport hors de cette exception. Un domaine peut contenir à la fois des applications internes et hébergées à l'extérieur.
L'explication originale de Mozilla distingue explicitement la correspondance d'IP littérales des noms qui se résolvent vers ces IP. Ce document est historique : vérifiez donc le comportement du client actuel et l'interface de stratégie avant d'en copier chaque exemple de syntaxe.
Quand la stratégie a besoin du DNS
Un fichier PAC offre un emplacement distinct et explicite pour les décisions tenant compte du DNS. Il introduit aussi des modes de défaillance de distribution, d'exécution et de résolution du script. Utilisez-le parce que l'exigence de routage a besoin de cette logique, pas simplement pour rendre une longue liste d'exception plus courte.
Dans une installation gérée, examinez aussi la stratégie effective de Firefox. Une stratégie de proxy verrouillée peut expliquer pourquoi une modification locale ne détermine pas la route.
Pour le dépannage, notez l'URL littérale que vous avez saisie, pas seulement l'IP finale du serveur. Comparer une URL de nom d'hôte à une URL d'adresse littérale change les informations disponibles pour la décision d'exception, et c'est précisément pourquoi les deux requêtes peuvent emprunter des chemins différents.