Per què una configuració de proxy HTTP no arregla una connexió PostgreSQL
Separeu el protocol de base de dades de PostgreSQL de l'encaminament HTTP i comproveu el camí de socket que necessita SOCKS.
http.proxyHost pot encaminar un client HTTP participant, però no fa res per a PostgreSQL JDBC. PostgreSQL envia el seu protocol de base de dades, no una sol·licitud HTTP.
L'URL de connexió JDBC encara ha de nomenar el servidor de base de dades i la base de dades. Substituir-ne el servidor per una adreça de proxy HTTP no pot ensenyar CONNECT al controlador.
Per a un servei SOCKS, investigueu la implementació de socket per sota de JDBC. Java exposa aquestes propietats d'inici per als sockets participants:
-DsocksProxyHost=203.0.113.10 -DsocksProxyPort=1080Substituïu el punt final de la documentació. Són arguments de JVM, no paràmetres d'URL de JDBC. Verifiqueu el camí real del socket del JDK/controlador i qualsevol fàbrica de sockets personalitzada abans d'esperar que els utilitzi.
Les propietats són per a tot el procés, així que incloeu altres connexions en l'avaluació d'impacte. Un connector dedicat documentat o un túnel aprovat poden oferir un límit més clar quan només el trànsit de base de dades ha de prendre la ruta.
El proxy encara necessita permís i accessibilitat al port de la base de dades. Després la base de dades aplica les regles d'accés d'amfitrió, el TLS de destinació i el seu propi inici de sessió. Conserveu el nom d'amfitrió del certificat i manteniu el compte de base de dades separat del compte del proxy.
Registreu la primera etapa fallida: connexió al proxy, negociació, TCP de base de dades, TLS o inici de sessió a la base de dades. Aquesta evidència identifica el canvi següent; ajustar repetidament propietats HTTP no utilitzades no pot fer-ho.