curl PAC faylınızı oxuya bilmir: əvəzinə proksini ötürün

PAC faylının ünvanı və proksi son nöqtəsi konfiqurasiya faylında bir-birini əvəz edə bilən kimi görünür, amma deyillər. Biri hər URL üçün qiymətləndirilməli olan siyasət proqramıdır; digəri isə bağlantıları qəbul edən host və portdur. curl yalnız ikincisini başa düşür. PAC ünvanını --proxy parametrinə ötürmək, adətən veb serverə uzun CONNECT gözləməsindən sonra çaşdırıcı şəkildə uğursuz olan kateqoriya səhvidir.

Hər birinin əslində nə olduğu

curl-un FAQ-ı bunu açıq şəkildə deyir: curl JavaScript və ya PAC təfsiri təqdim etmir. curl ətrafında PAC-u anlayan örtük bunu edə bilər, amma curl özü etmir və heç bir flag onu brauzerə çevirmir.

Brauzer niyə işləyir, curl isə yox

Brauzer sistemin proksi konfiqurasiyası ilə birləşir, PAC faylını gətirir və qaydalarını açdığınız URL-ə tətbiq edir. Bu qiymətləndirmə PAC faylının təqdim etdiyi xidmətdir və terminalınızda deyil, brauzerin içində baş verir.

PAC faylını curl ilə endirmək onun mətnini gətirir. Bu, curl-un siyasəti icra etməsinə səbəb olmur və proksi tapmaq üçün onu əl ilə oxumaq eyni qiymətləndirmənin əl ilə versiyasıdır, səhv budağı seçmək ehtimalı da eynidir. Əgər oxuyursunuzsa, fayldakı ilk proksi adını deyil, hostunuza uyğun gələn return ifadəsini oxuyun. Əksər PAC fayllarında bir neçə proksi olur və yalnız bir budaq sizə aiddir.

Təsdiqlənmiş HTTP proksisi və təsdiqlənmiş HTTPS xidməti üçün nümunə sorğu belədir:

curl --proxy http://proxy.corp.example:8080 https://service.example.net/status

Birinci ünvan proksi dinləyicisidir, ikincisi istədiyiniz xidmətdir. Bunlar kimsənin apardığı test deyil, nümunə son nöqtələrdir, ona görə təşkilatınızın sxemi, portu və autentifikasiya iş axını ilə əvəz edin.

Bu hədəf üçün proksini seçin

İnzibatçıdan təşkilatın hansı proksiyə sahib olduğunu deyil, siyasətin ehtiyacınız olan URL üçün hansı proksini seçdiyini soruşun. PAC qaydaları daxili xidmətlər, açıq saytlar və failover halları üçün fərqli nəticələr qaytara bilər və bu gün URL-inizə uyğun gələn qayda redaktədən sonra başqasına uyğun gələ bilər.

İş axını birdən çox məlum sorğu tələb edirsə, inzibatçının dəstəklədiyi statik parametrdən və ya təsdiqlənmiş PAC-u anlayan inteqrasiyadan istifadə edin. Kopyalanmış bir ünvanı kodda bərkitmək, siyasət dəyişən və o ünvanın niyə seçildiyini heç kimin xatırlamadığı günə qədər işləyir.

Sonra curl-un nəyi miras aldığına baxın. Proksi mühit dəyişənləri və NO_PROXY ötürdüyünüz proksini üstələyə və ya istisna edə bilər və hədəfinizə uyğun gələn istisna sorğunu səssizcə birbaşa göndərir. Hər istisnanı silmək və ya hər şeyi bir ünvandan keçməyə məcbur etmək əvəzinə nəzərdə tutulan siyasəti qoruyun. Sorğunu bir dəfə -v ilə işə salın və həqiqətən hansı ünvana qoşulduğunu yoxlayın.

İki TLS kimliyini ayrı saxlayın

HTTPS proksisi ilə iki TLS bağlantısı işə düşür: sizin proksiyə olan bağlantınız və proksinin hədəfə olan bağlantısı. Hər birinin yoxlanmalı öz kimliyi var və onlardan biri üçün yoxlamanı söndürmək PAC həlli deyil, birinciyə əlavə olunan ikinci problemdir.

Yoxlamanı aktiv saxlayın və aldığınız xətanı oxuyun. Proksi autentifikasiya çağırışı, əlçatmaz proksi və saytdan imtina üç fərqli nəticədir və yalnız birincisi etimadnamələrlə bağlıdır. VPN hələ də özəl proksiyə icazə verilmiş yol təqdim etməlidir, o cümlədən proksi hostunun özü üçün ad həlli, ondan əvvəl bunların heç biri uğurlu ola bilməz.

Son nöqtəni, sxemi, portu, autentifikasiya üsulunu, istisnaları və proksiyə qədər VPN yolunu yazın. Bu qeyd növbəti sorğunu təkrar edilə bilən edən şeydir və proksinizi bilməklə onu təxmin etmək arasındakı fərqdir.