Pourquoi un réglage de proxy HTTP ne répare pas une connexion PostgreSQL

http.proxyHost peut router un client HTTP participant sans rien faire pour PostgreSQL JDBC. PostgreSQL envoie son protocole de base de données, pas une requête HTTP.

L'URL de connexion JDBC doit toujours nommer le serveur de base de données et la base de données. Remplacer son serveur par une adresse de proxy HTTP ne peut pas apprendre CONNECT au pilote.

Pour un service SOCKS, examinez l'implémentation de socket sous JDBC. Java expose ces propriétés de démarrage pour les sockets participantes :

-DsocksProxyHost=203.0.113.10 -DsocksProxyPort=1080

Remplacez le point de terminaison de la documentation. Ce sont des arguments JVM, pas des paramètres d'URL JDBC. Vérifiez le chemin de socket réel du JDK/pilote et toute fabrique de sockets personnalisée avant de compter qu'il les utilise.

Les propriétés s'appliquent à tout le processus ; incluez donc les autres connexions dans l'évaluation d'impact. Un connecteur dédié documenté ou un tunnel approuvé peut offrir une frontière plus claire lorsque seul le trafic de base de données doit emprunter la route.

Le proxy a toujours besoin d'une autorisation et d'un accès au port de la base de données. La base de données applique ensuite les règles d'accès de l'hôte, le TLS de destination et sa propre connexion. Conservez le nom d'hôte du certificat et gardez le compte de base de données distinct du compte du proxy.

Consignez la première étape en échec : connexion au proxy, négociation, TCP de la base de données, TLS ou connexion à la base de données. Cette preuve identifie le changement suivant ; ajuster à répétition des propriétés HTTP inutilisées ne peut pas y parvenir.