http.proxyHost می‌تواند یک کلاینت HTTP مشارکت‌کننده را مسیریابی کند، اما برای PostgreSQL JDBC کاری نمی‌کند. PostgreSQL پروتکل پایگاه داده خود را می‌فرستد، نه یک درخواست HTTP.

نشانی اتصال JDBC هنوز باید سرور پایگاه داده و پایگاه داده را نام ببرد. جایگزینی سرور آن با نشانی پروکسی HTTP نمی‌تواند به درایور CONNECT را بیاموزد.

برای یک سرویس SOCKS، پیاده‌سازی سوکت در زیر JDBC را بررسی کنید. جاوا این ویژگی‌های راه‌اندازی را برای سوکت‌های مشارکت‌کننده ارائه می‌دهد:

-DsocksProxyHost=203.0.113.10 -DsocksProxyPort=1080

نقطه پایانی مستندات را جایگزین کنید. این‌ها آرگومان‌های JVM هستند، نه پارامترهای نشانی JDBC. مسیر واقعی سوکت JDK/درایور و هر کارخانه سوکت سفارشی را پیش از انتظار برای استفاده از آن‌ها بررسی کنید.

این ویژگی‌ها برای کل فرایند اعمال می‌شوند، بنابراین اتصال‌های دیگر را در ارزیابی تأثیر بگنجانید. یک اتصال‌دهنده اختصاصی مستند یا تونل تأییدشده می‌تواند مرز روشن‌تری فراهم کند وقتی فقط ترافیک پایگاه داده باید این مسیر را طی کند.

پروکسی هنوز به اجازه و دسترسی به پورت پایگاه داده نیاز دارد. سپس پایگاه داده قواعد دسترسی میزبان، TLS مقصد و ورود خودش را اعمال می‌کند. نام میزبان گواهی را حفظ کنید و حساب پایگاه داده را از حساب پروکسی جدا نگه دارید.

نخستین مرحله ناموفق را ثبت کنید: اتصال پروکسی، مذاکره، TCP پایگاه داده، TLS یا ورود به پایگاه داده. این شواهد تغییر بعدی را مشخص می‌کند؛ تنظیم مکرر ویژگی‌های HTTP بی‌استفاده نمی‌تواند چنین کند.

مقالات مرتبط