چرا curl به جای URL راه دور به localhost وصل میشود
پیش از سرزنش VPN، پروکسی ارثرسیده، فایل curlrc پیشفرض و مقصد واقعی را از هم جدا کنید. سه اجرای کنترلشده بررسی TLS را روشن نگه میدارند.
اگر curl صرفنظر از URLی که دادهاید تلاش کند به localhost وصل شود، VPN جای اشتباهی برای شروع است. ممکن است یک پروکسی محلی HTTP یا SOCKS همان اولین اتصال موردنظر باشد، حتی وقتی سرویسی که میخواهید جای کاملاً دیگری است. اگر آن پروکسی دیگر اجرا نشود، تلاش برای localhost پیش از آنکه curl هرگز به مقصد برسد شکست میخورد. پاسخ پروکسی هم اثبات آن نیست که مقصد پاسخ داده است.
این مراحل را به ترتیب انجام دهید و در اولین مرحلهای که اولین تلاش اتصال را تغییر میدهد توقف کنید.
نخست قواعد پروکسی خود curl را بخوانید
curl متغیرهای پروکسی مخصوص پروتکل را میخواند، مانند https_proxy و HTTPS_PROXY، بهعلاوه ALL_PROXY هنگامی که هیچ مقدار مخصوص پروتکلی اعمال نمیشود. محیط پوسته، سرویس یا وظیفهای را بررسی کنید که واقعاً curl را اجرا میکند، نه محیط ترمینال فعلیتان را. یک کار CI، یک واحد systemd و یک پوسته تعاملی میتوانند سه مجموعه متفاوت را به ارث ببرند. حدس زدن از روی پوسته دیدهشده همان چیزی است که این بررسی را یک بعدازظهر کامل هدر میدهد.
یک استثنا ارزش به خاطر سپردن دارد. curl http_proxy را فقط با حروف کوچک میپذیرد؛ شکل با حروف بزرگ HTTP_PROXY نادیده گرفته میشود، و به همین دلیل همان محیط در ابزارهای دیگر رفتار متفاوتی دارد.
مقادیر را خصوصی بخوانید، چون URL پروکسی اغلب اعتبارنامه حمل میکند.
سپس فایل پیکربندی پیشفرض curl را از نظر بازنویسیهای پروکسی یا اتصال بررسی کنید و تأیید کنید کدام فایل اجرایی را واقعاً اجرا میکنید. یک نام مستعار پوسته، یک تابع یا یک اسکریپت پوششی میتواند گزینههایی اضافه کند که هرگز در خط فرمان شما دیده نمیشوند.
سه فراخوانی را با TLS روشن مقایسه کنید
برای هر سه اجرا از یک مقصد تشخیصی تأییدشده و همان فایل دودویی استفاده کنید.
curl -v https://service.corp.example/status
curl -q -v https://service.corp.example/status
curl -q --proxy '' -v https://service.corp.example/status
-q فایل curlrc پیشفرض را سرکوب میکند و برای کار کردن باید اولین پارامتر خط باشد. متغیرهای محیطی پروکسی را حذف نمیکند، و همین کسانی را که انتظار چنین کاری دارند شگفتزده میکند. شکل سوم یک مقدار خالی --proxy اضافه میکند و پروکسی درخواستی محیط را فقط برای همان فراخوانی بازنویسی میکند. اولین تلاش اتصال را در هر خروجی مقایسه کنید، نه کد وضعیت نهایی را.
خروجی مشروح میتواند سرآیندها، توکنها و اعتبارنامههای پروکسی را افشا کند، پس آن را محلی نگه دارید و پیش از به اشتراک گذاشتن، بخشهایی را بخوانید.
هر نتیجه چه چیزی را رد میکند
اگر حذف پیکربندی پیشفرض اتصال را تغییر دهد، منبع همان فایل پیکربندی است. اگر غیرفعال کردن صریح پروکسی ارثرسیده آن را تغییر دهد، منبع همان متغیر محیطی است. اگر هیچکدام آن را تغییر ندهند و localhost هنوز ظاهر شود، بازنویسیهای اتصال در خط فرمان، حل نام میزبان و فایل اجرایی انتخابشده را بررسی کنید. هر یک از اینها اصلاح متفاوتی دارد و هیچیک تغییر مسیریابی نیست.
بارگذاری کتابخانه سفارشی یا رفتار شبکه تزریقشده لایه بعدی است و یک متغیر محیطی بهتنهایی اثبات آن نیست.
تصمیم پروکسی را از VPN جدا نگه دارید
وقتی curl مقصد مستقیمی انتخاب میکند، سیستمعامل همچنان آن اتصال را مسیریابی میکند. غیرفعال کردن پروکسی یک برنامه مسیر VPN یا سیاست فیلترکردن آن را غیرفعال نمیکند. مقایسههای دسترسی مستقیم را فقط جایی انجام دهید که آن تشخیص مجاز است. آزمونی که بیصدا سیاست را دور میزند نتیجه معتبری نیست، یک رخداد است.
اگر پروکسی محلی لازم است، سرویس و نشانی آن را بازیابی کنید، نه اینکه تنظیماتش را پاک کنید.
اگر فقط مقصدهای خصوصی برگزیده به دسترسی مستقیم نیاز دارند، یک استثنای باریک تأییدشده اضافه کنید و پروکسی را برای بقیه چیزها نگه دارید. اولین خطا را از مسیر انتخابشده نگه دارید، چون رد localhost، رد CONNECT پروکسی، شکست گواهی و خطای مجوز چهار مرحله متفاوت را مشخص میکنند.