Warum eine HTTP-Proxy-Einstellung keine PostgreSQL-Verbindung repariert
Trennen Sie das Datenbankprotokoll von PostgreSQL vom HTTP-Routing und prüfen Sie den für SOCKS nötigen Socket-Pfad.
http.proxyHost kann einen teilnehmenden HTTP-Client weiterleiten, bewirkt aber nichts für PostgreSQL JDBC. PostgreSQL sendet sein Datenbankprotokoll, keine HTTP-Anfrage.
Die JDBC-Verbindungs-URL muss weiterhin den Datenbankserver und die Datenbank nennen. Ihren Server durch eine HTTP-Proxy-Adresse zu ersetzen, kann dem Treiber CONNECT nicht beibringen.
Untersuchen Sie bei einem SOCKS-Dienst die Socket-Implementierung unterhalb von JDBC. Java stellt diese Starteigenschaften für teilnehmende Sockets bereit:
-DsocksProxyHost=203.0.113.10 -DsocksProxyPort=1080Ersetzen Sie den Endpunkt aus der Dokumentation. Dies sind JVM-Argumente, keine JDBC-URL-Parameter. Prüfen Sie den tatsächlichen Socket-Pfad von JDK/Treiber und jede benutzerdefinierte Socket-Factory, bevor Sie erwarten, dass sie verwendet werden.
Die Eigenschaften gelten prozessweit, beziehen Sie also andere Verbindungen in die Auswirkungsanalyse ein. Ein dokumentierter dedizierter Connector oder ein freigegebener Tunnel kann eine klarere Grenze bieten, wenn nur Datenbankverkehr die Route nehmen soll.
Der Proxy benötigt weiterhin Berechtigung und Erreichbarkeit des Datenbankports. Anschließend wendet die Datenbank Hostzugriffsregeln, Ziel-TLS und ihren eigenen Login an. Bewahren Sie den Zertifikats-Hostnamen und halten Sie das Datenbankkonto vom Proxy-Konto getrennt.
Halten Sie die erste fehlgeschlagene Stufe fest: Proxy-Verbindung, Aushandlung, Datenbank-TCP, TLS oder Datenbank-Login. Diese Evidenz bestimmt die nächste Änderung; wiederholtes Anpassen ungenutzter HTTP-Eigenschaften kann das nicht leisten.