اتصال به broker Artemis که با رمز عبور نادرست SOCKS موفق می‌شود ممکن است از handler پروکسی عبور کرده باشد. مقصد broker را بررسی کنید، نه فقط socksHost را.

مستندات transport نشانی‌های broker از نوع loopback مانند localhost و 127.0.0.1 را نشانی‌هایی توصیف می‌کند که از پیکربندی SOCKS عبور می‌کنند. برای مسیر عادی حل محلی، وقتی اتصال باید از واسطه عبور کند از نشانی broker غیر loopback موردنظر استفاده کنید. alias دیگری که هنوز به loopback حل می‌شود ممکن است همان نتیجه را بدهد.

شرط دقیق نسخه connector را بررسی کنید

کد منبع جدیدتر connector در upstream شامل استثنای صریح remote-DNS است. شرط handler پروکسی این است:

socksEnabled && (socksRemoteDNS || !isTargetLocalHost())

وقتی socksRemoteDNS در پیاده‌سازی‌ای که آن شرط را دارد فعال باشد، connector مقصد را حل‌نشده نگه می‌دارد و handler SOCKS را حتی برای مقصدی که شبیه loopback است نصب می‌کند. با مقدار پیش‌فرض مستند false، آزمون نشانی محلی همچنان مهم است.

این معنای نام میزبانی مانند localhost را تغییر می‌دهد: وقتی برای حل به سرور SOCKS داده می‌شود، به دیدگاه پروکسی از مقصد اشاره می‌کند. پیش از انتخاب حل از راه دور تأیید کنید که این همان مکان موردنظر broker است.

رفتار را با client نصب‌شده Artemis هماهنگ کنید. وقتی handler واقعاً در مسیر قرار گرفت، احراز هویت SOCKS را از احراز هویت broker جدا کنید و مسیر اتصال حاصل را بررسی کنید، نه اینکه یک نشست موفق broker را دلیل استفاده از اعتبارنامه‌های پروکسی بدانید.

مقالات مرتبط