Kial HTTP-proksa agordo ne riparas PostgreSQL-konekton
Apartigu la datumbazan protokolon de PostgreSQL disde HTTP-enkursigo kaj kontrolu la soketan vojon bezonatan por SOCKS.
http.proxyHost povas enkursigi partoprenantan HTTP-klienton, sed faras nenion por PostgreSQL JDBC. PostgreSQL sendas sian datumbazan protokolon, ne HTTP-peton.
La JDBC-konekta URL devas ankoraŭ nomi la datumbazan servilon kaj la datumbazon. Anstataŭigi ĝian servilon per HTTP-proksa adreso ne povas instrui CONNECT al la pelilo.
Por SOCKS-servo, esploru la soketan efektivigon sub JDBC. Java elmetas ĉi tiujn startajn ecojn por partoprenantaj soketoj:
-DsocksProxyHost=203.0.113.10 -DsocksProxyPort=1080Anstataŭigu la finpunkton de la dokumentaro. Ĉi tiuj estas JVM-argumentoj, ne JDBC-URL-parametroj. Kontrolu la realan soketan vojon de JDK/pelilo kaj ajnan propran soketan fabrikon antaŭ ol atendi, ke ĝi uzos ilin.
La ecoj validas por la tuta procezo, do inkluzivu aliajn konektojn en la efika takso. Dokumentita dediĉita konektilo aŭ aprobita tunelo povas doni pli klaran limon, kiam nur datumbaza trafiko devus preni la vojon.
La prokso ankoraŭ bezonas permeson kaj atingeblon de la datumbaza pordo. Poste la datumbazo aplikas gastigantajn alirregulojn, celan TLS kaj sian propran saluton. Konservu la gastigantnomon de la atestilo kaj tenu la datumbazan konton aparte de la proksa konto.
Registru la unuan malsukcesan stadion: proksa konekto, traktado, datumbaza TCP, TLS aŭ datumbaza saluto. Tiu pruvo identigas la sekvan ŝanĝon; ripeta ĝustigo de neuzitaj HTTP-ecoj ne povas tion fari.