Ինչու HTTP վստահված սերվերի կարգավորումը չի շտկում PostgreSQL միացումը

http.proxyHost կարող է երթուղավորել մասնակցող HTTP հաճախորդին, բայց ոչինչ չի անում PostgreSQL JDBC-ի համար։ PostgreSQL-ը ուղարկում է իր տվյալների բազայի արձանագրությունը, ոչ թե HTTP հարցում։

JDBC միացման URL-ը դեռ պետք է նշի տվյալների բազայի սերվերը և տվյալների բազան։ Սերվերը HTTP վստահված սերվերի հասցեով փոխարինելը չի կարող դրայվերին սովորեցնել CONNECT։

SOCKS ծառայության համար ուսումնասիրեք JDBC-ից ներքև գտնվող socket-ի իրականացումը։ Java-ն տրամադրում է այս մեկնարկային հատկությունները մասնակցող socket-ների համար՝

-DsocksProxyHost=203.0.113.10 -DsocksProxyPort=1080

Փոխարինեք փաստաթղթի վերջնակետը։ Սրանք JVM արգումենտներ են, ոչ թե JDBC URL պարամետրեր։ Ստուգեք իրական JDK/դրայվերի socket ուղին և ցանկացած հատուկ socket գործարան, նախքան դրանց օգտագործումը սպասելը։

Հատկությունները գործում են ամբողջ գործընթացի համար, ուստի ազդեցության գնահատման մեջ ներառեք նաև այլ միացումներ։ Փաստաթղթավորված հատուկ միակցիչը կամ հաստատված թունելը կարող են ավելի հստակ սահման տալ, երբ միայն տվյալների բազայի երթևեկությունը պետք է անցնի այդ ուղով։

Վստահված սերվերը դեռ պահանջում է թույլտվություն և հասանելիություն տվյալների բազայի պորտին։ Այնուհետև տվյալների բազան կիրառում է հոսթի մուտքի կանոնները, նպատակակետի TLS-ը և իր սեփական մուտքը։ Պահպանեք վկայագրի հոսթի անունը և տվյալների բազայի հաշիվը առանձին պահեք վստահված սերվերի հաշվից։

Գրանցեք առաջին ձախողված փուլը՝ վստահված սերվերի միացում, բանակցություն, տվյալների բազայի TCP, TLS կամ տվյալների բազայի մուտք։ Այդ ապացույցը որոշում է հաջորդ փոփոխությունը. չօգտագործվող HTTP հատկությունների կրկնվող կարգավորումը չի կարող դա անել։