Чаму налада HTTP-проксі не выпраўляе злучэнне з PostgreSQL

http.proxyHost можа маршрутызаваць удзельны HTTP-кліент, але нічога не робіць для PostgreSQL JDBC. PostgreSQL перадае пратакол сваёй базы даных, а не HTTP-запыт.

URL злучэння JDBC па-ранейшаму павінен указваць сервер базы даных і саму базу. Замена сервера адрасам HTTP-проксі не навучыць драйвер камандзе CONNECT.

Для службы SOCKS даследуйце рэалізацыю сокета ніжэй за JDBC. Java прадастаўляе гэтыя ўласцівасці запуску для ўдзельных сокетаў:

-DsocksProxyHost=203.0.113.10 -DsocksProxyPort=1080

Замяніце канечную кропку з дакументацыі. Гэта аргументы JVM, а не параметры URL JDBC. Праверце фактычны шлях сокета JDK/драйвера і любую ўласную фабрыку сокетаў, перш чым спадзявацца, што яны будуць выкарыстаны.

Уласцівасці дзейнічаюць на ўвесь працэс, таму ўключыце іншыя злучэнні ў ацэнку ўплыву. Задакументаваны спецыяльны канэктар або ўзгоднены тунель могуць даць больш ясную мяжу, калі праз гэты шлях павінен ісці толькі трафік базы даных.

Проксі ўсё яшчэ патрабуе дазволу і даступнасці порта базы даных. Затым база даных прымяняе правілы доступу да хоста, TLS прызначэння і ўласны ўваход. Захавайце імя хоста сертыфіката і трымайце ўліковы запіс базы даных асобна ад уліковага запісу проксі.

Запішыце першую няўдалую стадыю: злучэнне з проксі, перамовы, TCP базы даных, TLS або ўваход у базу даных. Гэтыя доказы вызначаюць наступную змену; паўторнае змяненне невыкарыстаных уласцівасцей HTTP зрабіць гэта не можа.