Prüfen Sie DNS dort, wo die fehlgeschlagene Abfrage stattfindet. Dass Ihr Laptop einen Namen auflösen kann, belegt nicht, dass Squid oder ein Parent-Proxy, der die weiterführende Verbindung herstellt, das ebenfalls kann.

Lesen Sie das Cache-Log der betroffenen Instanz und prüfen Sie die Resolvereinstellungen des Servers. Eine ergänzende Prüfung auf Hostebene ist:

getent ahosts target.example

Verwenden Sie das tatsächliche Ziel. getent nutzt die Namensauflösung des Hosts; Squids interner Resolver oder Cache kann davon abweichen. Prüfen Sie explizite Angaben für dns_nameservers und hosts_file, bevor Sie Übereinstimmung annehmen.

Bei Squid 6.13 enthält eine explizite Nameserverliste IP-Adressen:

dns_nameservers 192.0.2.53

Ersetzen Sie diese Dokumentationsadresse durch einen freigegebenen Resolver, der vom Squid-Server aus erreichbar ist. Private Namen können den Resolver der Organisation erfordern; ein unbeteiligter öffentlicher Resolver kann sie in seiner DNS-Sicht nicht kennen.

Ein Alias aus der hosts-Datei des Laptops wird bei einer Proxyanfrage mit Hostnamen nicht mitübertragen. Prüfen Sie auf dem Rechner, der die Abfrage ausführt, die hosts_file-Einstellung der installierten Squid-Version und berücksichtigen Sie gegebenenfalls den Resolver eines Parent-Proxys. Der für die TLS-Identität verwendete Hostname muss zum Dienst passen.

Prüfen Sie nach einer einzelnen kontrollierten Konfigurationsänderung die Konfigurationssyntax und laden Sie die gewünschte Instanz neu, wiederholen Sie dieselbe Anfrage und untersuchen Sie die zugehörigen Belege. Positive und negative Antworten im Cache können Wiederholungstests beeinflussen. Eine erfolgreiche Namensauflösung mit anschließendem Verbindungs-Timeout ist ein nachgelagerter Routing- oder Berechtigungsfehler; ändern Sie dafür nicht weiter DNS. Halten Sie Client-DNS, Parent-Routing und Proxyprotokoll während der Bewertung der Serveränderung konstant.

Ähnliche Artikel