Miks HTTP-puhverserveri säte ei paranda PostgreSQL-ühendust
Eraldage PostgreSQL-i andmebaasiprotokoll HTTP-marsruutimisest ja kontrollige SOCKS-i jaoks vajalikku socketi teed.
http.proxyHost saab suunata osalevat HTTP-kliendini, kuid ei tee PostgreSQL JDBC jaoks midagi. PostgreSQL saadab oma andmebaasiprotokolli, mitte HTTP-päringut.
JDBC-ühenduse URL peab endiselt nimetama andmebaasiserverit ja andmebaasi. Serveri asendamine HTTP-puhverserveri aadressiga ei suuda draiverile CONNECT-i õpetada.
SOCKS-teenuse puhul uurige JDBC all olevat socketi teostust. Java pakub osalevate socketite jaoks järgmisi käivitusomadusi:
-DsocksProxyHost=203.0.113.10 -DsocksProxyPort=1080Asendage dokumentatsiooni lõpp-punkt. Need on JVM-i argumendid, mitte JDBC URL-i parameetrid. Enne nende kasutamise ootamist kontrollige tegelikku JDK/draiveri socketi teed ja mis tahes kohandatud socketi tehast.
Omadused kehtivad kogu protsessi kohta, seega kaasake mõju hindamisse ka teised ühendused. Dokumenteeritud spetsiaalne pistik või kinnitatud tunnel võib pakkuda selgemat piiri, kui marsruuti peaks kasutama ainult andmebaasiliiklus.
Puhverserver vajab endiselt luba ja juurdepääsu andmebaasi pordile. Seejärel rakendab andmebaas hosti juurdepääsureegleid, sihtkoha TLS-i ja oma sisselogimist. Säilitage sertifikaadi hostinimi ja hoidke andmebaasi konto puhverserveri kontost eraldi.
Registreerige esimene ebaõnnestunud etapp: puhverserveri ühendus, läbirääkimine, andmebaasi TCP, TLS või andmebaasi sisselogimine. See tõend määrab järgmise muudatuse; kasutamata HTTP-omaduste korduv kohandamine ei suuda seda teha.