Waarom 'n HTTP-proxyinstelling nie 'n PostgreSQL-verbinding regmaak nie
Skei PostgreSQL se databasisprotokol van HTTP-roetering en ondersoek die socketpad wat SOCKS nodig het.
http.proxyHost kan 'n deelnemende HTTP-kliënt roeteer, maar doen niks aan PostgreSQL JDBC nie. PostgreSQL stuur sy databasisprotokol, nie 'n HTTP-versoek nie.
Die JDBC-verbindings-URL moet steeds die databasisbediener en die databasis noem. Om die bediener met 'n HTTP-proxyadres te vervang, kan nie die drywer CONNECT leer nie.
Ondersoek vir 'n SOCKS-diens die socket-implementering onder JDBC. Java stel hierdie opstarteienskappe beskikbaar vir deelnemende sockets:
-DsocksProxyHost=203.0.113.10 -DsocksProxyPort=1080Vervang die dokumentasie-eindpunt. Dit is JVM-argumente, nie JDBC-URL-parameters nie. Verifieer die werklike JDK/drywer-socketpad en enige pasgemaakte socketfabriek voordat jy verwag dat dit hulle sal gebruik.
Die eienskappe geld vir die hele proses, so sluit ander verbindings by die impakbeoordeling in. 'n Gedokumenteerde toegewyde verbinding of goedgekeurde tonnel kan 'n duideliker grens bied wanneer net databasiskverkeer die roete moet volg.
Die proxy het steeds toestemming en bereikbaarheid na die databasispoort nodig. Die databasis pas dan gasheertoegangsreëls, TLS vir die bestemming en sy eie aanmelding toe. Bewaar die sertifikaathostnaam en hou die databasisrekening apart van die proxyrekening.
Teken die eerste mislukte stadium aan: proxyverbinding, onderhandeling, databasis-TCP, TLS of databasisaanmelding. Daardie bewyse wys die volgende verandering; herhaaldelik aanpas van ongebruikte HTTP-eienskappe kan dit nie doen nie.