የHTTP ፕሮክሲ ቅንብር የPostgreSQL ግንኙነትን ለምን አይፈታም
የPostgreSQL የውሂብ ጎታ ፕሮቶኮልን ከHTTP ማዞር ለይተው ለSOCKS የሚያስፈልገውን የሶኬት መንገድ ይመርምሩ።
http.proxyHost ተሳታፊ የሆነውን HTTP ደንበኛ ማዞር ይችላል፣ ነገር ግን ለPostgreSQL JDBC ምንም አያደርግም። PostgreSQL የሚልከው የውሂብ ጎታ ፕሮቶኮሉን ነው፣ የHTTP ጥያቄን አይደለም።
የJDBC ግንኙነት URL አሁንም የውሂብ ጎታውን አገልጋይ እና የውሂብ ጎታውን መጥቀስ አለበት። አገልጋዩን በHTTP ፕሮክሲ አድራሻ መተካት ለአሽከርካሪው CONNECT ማስተማር አይችልም።
ለSOCKS አገልግሎት ከJDBC በታች ያለውን የሶኬት አተገባበር ይመርምሩ። Java ለተሳታፊ ሶኬቶች እነዚህን የጅምር ባህሪያት ያቀርባል፦
-DsocksProxyHost=203.0.113.10 -DsocksProxyPort=1080የሰነዱን መጨረሻ ነጥብ ይተኩ። እነዚህ የJVM ነጋሪ እሴቶች ናቸው፣ የJDBC URL መለኪያዎች አይደሉም። ትክክለኛውን የJDK/አሽከርካሪ የሶኬት መንገድ እና ማንኛውንም ብጁ የሶኬት ፋብሪካ ከመጠበቅዎ በፊት ያረጋግጡ።
ባህሪያቱ በጠቅላላው ሂደት ላይ ተግባራዊ ናቸው፣ ስለዚህ ሌሎች ግንኙነቶችን በተጽዕኖ ግምገማው ውስጥ ያካትቱ። የተመዘገበ የተወሰነ አገናኝ ወይም የጸደቀ ዋሻ የውሂብ ጎታ ትራፊክ ብቻ መንገዱን መውሰድ ሲኖርበት የበለጠ ግልጽ ወሰን ሊሰጥ ይችላል።
ፕሮክሲው አሁንም የውሂብ ጎታ ወደብ ፈቃድ እና ተደራሽነት ይፈልጋል። ከዚያም የውሂብ ጎታው የአስተናጋጅ መዳረሻ ደንቦችን፣ የመድረሻ TLS እና የራሱን መግቢያ ይተገብራል። የምስክር ወረቀቱን የአስተናጋጅ ስም ይጠብቁ እና የውሂብ ጎታ መለያውን ከፕሮክሲ መለያ ለያዩት።
የመጀመሪያውን የተሳነውን ደረጃ ይመዝግቡ፦ የፕሮክሲ ግንኙነት፣ ድርድር፣ የውሂብ ጎታ TCP፣ TLS ወይም የውሂብ ጎታ መግቢያ። ያ ማስረጃ ቀጣዩን ለውጥ ይለያል፤ ጥቅም ላይ ያልዋሉ የHTTP ባህሪያትን ተደጋግመው ማስተካከል ይህን ማድረግ አይችልም።