Pourquoi un proxy inverse fonctionne-t-il par domaine mais échoue par adresse IP locale ?

Un reverse proxy fonctionne par domaine car ses règles de routage et TLS dépendent souvent du nom d'hôte demandé, pas seulement de l'IP de destination.

Lorsqu'un client domestique ouvre https://app.example.com, le DNS fournit une IP mais le navigateur envoie toujours le domaine via la négociation TLS et l'en-tête HTTP Host. Ouvrir https://192.168.1.20 modifie ces identifiants, donc le proxy peut sélectionner un site par défaut, rejeter le certificat, manquer la route de l'application ou rediriger vers l'URL publique configurée. Le test correct préserve le nom d'hôte prévu tout en ne changeant que la destination réseau.

Comparer la requête par nom d'hôte avec la requête par IP directe

Envoyez une requête au domaine et une à l'IP locale, puis comparez le code de statut, le certificat, les en-têtes de réponse, la localisation de redirection et le journal d'accès du reverse proxy. Ne supposez pas que les deux requêtes sont équivalentes parce qu'elles atteignent la même interface Ethernet.

Un tutoriel sur le reverse proxy en homelab explique que le proxy inspecte l'en-tête HTTP Host pour router plusieurs services via une seule IP et un seul port.

Si la requête par domaine correspond à une route d'application tandis que la requête par IP aboutit à une page par défaut ou une erreur 404, le proxy fonctionne comme configuré. La décision suivante est de savoir si l'accès direct par IP est réellement nécessaire ou si le DNS local doit préserver le domaine.

Tester l'IP locale tout en préservant l'en-tête Host prévu

Utilisez un outil client qui se connecte à l'IP locale du proxy tout en envoyant le domaine de l'application comme en-tête Host. Pour HTTPS, conservez aussi le domaine comme nom de serveur TLS au lieu de le remplacer par l'IP.

Server Fault décrit comment un reverse proxy HTTP peut utiliser l'en-tête Host pour choisir la route de la même manière que les hôtes virtuels basés sur le nom.

Si la requête avec Host forcé réussit, la route du proxy et le backend sont sains ; l'échec par IP directe est un problème d'identité. Si cela échoue encore, inspectez l'écoute, le pare-feu local, le point d'entrée du proxy et la priorité des routes avant de modifier le DNS.

Vérifier la correspondance TLS SNI et certificat

HTTPS ajoute une décision de nom d'hôte avant la requête HTTP. Le client envoie généralement une indication de nom de serveur (SNI) lors de la négociation TLS pour que le proxy puisse sélectionner le bon certificat et l'hôte virtuel sécurisé.

Une implémentation de reverse proxy SNI note que les backends HTTPS sont sélectionnés en utilisant le nom SNI du client avant que les en-têtes HTTP ordinaires ne soient examinés.

L'accès direct par IP peut présenter un certificat par défaut ou échouer à la validation du nom d'hôte même si le proxy est accessible. Utilisez le domaine avec un DNS local, ou déployez un certificat géré contenant l'IP uniquement si l'HTTPS direct par IP est une exigence opérationnelle réelle.

Featured

ZimaCube 2 NAS personnel Cloud à domicile

ZimaCube2

$799.00 - $2,499.00

Buy Now

Inspecter le site par défaut et la priorité des routes

Vérifiez quel hôte virtuel gère les requêtes qui ne correspondent pas à un domaine configuré. Un site par défaut peut retourner un tableau de bord, rediriger vers un autre nom d'hôte, fermer la connexion ou afficher une erreur générique.

Une discussion sur Caddy montre qu'une requête peut atteindre la bonne IP du proxy tandis que l'en-tête Host et le nom TLS déterminent toujours si l'amont prévu est choisi.

Gardez la route par défaut explicite et sûre. N'ajoutez pas un proxy catch-all large vers un seul backend juste pour faire fonctionner l'accès par IP, car cela peut router des noms d'hôtes inconnus ou du trafic de scan vers une application censée être restreinte au domaine.

Vérifier si l'application redirige vers son URL canonique

Même si le proxy accepte la requête par IP, le backend peut appliquer une URL publique de base configurée et rediriger le navigateur vers le domaine. Les cookies d'authentification, les callbacks OAuth, les origines WebSocket et les vérifications CSRF peuvent aussi dépendre de cet hôte canonique.

Comparez le journal du proxy avec celui de l'application et inspectez l'en-tête Location. Une redirection vers le domaine n'est pas un échec de routage ; c'est la preuve que l'application attend une identité publique unique.

Corrigez les en-têtes Host et protocole transmis lorsque l'application génère une mauvaise URL externe. Ne remplacez pas le domaine canonique par une IP privée juste pour contourner la redirection, car cela peut casser les certificats et l'accès distant.

Utiliser un DNS local lorsque le domaine est l'interface prévue

Créez un enregistrement DNS interne qui résout le domaine de l'application vers l'adresse locale du reverse proxy. Le navigateur utilise alors le chemin LAN efficace tout en préservant le même en-tête Host, nom SNI, certificat, cookies et URL de l'application.

La comparaison ZimaSpace de reverse proxies et chemins d'accès privés aide à décider si le domaine doit rester un point d'entrée local et public ou rester derrière un réseau privé.

Le problème est résolu lorsque le domaine fonctionne à la fois à l'intérieur et à l'extérieur via des réponses DNS intentionnelles, tandis que l'IP directe atteint soit un site par défaut documenté soit est délibérément rejetée. Un proxy routé par domaine n'a pas besoin de se comporter comme un serveur à site unique adressé par IP.