curl haiwezi kusoma faili yako ya PAC: pitisha proxy badala yake

Anwani ya faili ya PAC na kituo cha mwisho cha proxy vinaonekana kubadilishana katika faili ya usanidi, na sivyo. Kimoja ni programu ya sera inayopaswa kutathminiwa kwa kila URL; kingine ni mwenyeji na bandari inayokubali miunganisho. curl inaelewa cha pili tu. Kupitisha anwani ya PAC kwa --proxy ni kosa la aina ambalo hushindwa kwa njia ya kuchanganya, kwa kawaida baada ya muda mrefu wa CONNECT kwa seva ya wavuti.

Kila kimoja ni nini hasa

Hilo linasema wazi maswali yanayoulizwa mara kwa mara kuhusu curl: curl haitoi tafsiri yoyote ya JavaScript au PAC. Kifuniko karibu na curl kinachoelewa PAC kinaweza, lakini curl yenyewe haifanyi, na hakuna bendera inayouigeuza kuwa kivinjari.

Kwa nini kivinjari kinafanya kazi na curl haifanyi

Kivinjari hujumuika na usanidi wa proxy wa mfumo, hupakua faili ya PAC na kuendesha kanuni zake dhidi ya URL unayofungua. Tathmini hiyo ni huduma ambayo faili ya PAC inatoa, na hufanyika ndani ya kivinjari, si ndani ya terminal yako.

Kupakua faili ya PAC kwa curl hupata maandishi yake tu. Haifanyi curl itekeleze sera, na kuisoma kwa mkono ili kupata proxy ni toleo la mkono la tathmini hiyo hiyo, likiwa na nafasi sawa ya kuchagua tawi lisilo sahihi. Ukisoma, soma taarifa ya return inayoendana na mwenyeji wako badala ya jina la kwanza la proxy kwenye faili. Faili nyingi za PAC zina kadhaa, na tawi moja tu linakuhusu.

Kwa proxy ya HTTP iliyoidhinishwa na huduma ya HTTPS iliyoidhinishwa, ombi la mfano ni:

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

Anwani ya kwanza ni msikilizaji wa proxy, ya pili ni huduma unayotaka. Hivi ni vituo vya mwisho vya mfano na si jaribio lililofanywa na mtu, kwa hivyo vibadilishe na mpango, bandari na mtiririko wa uthibitishaji wa shirika lako.

Chagua proxy kwa lengo hili

Muulize msimamizi ni proxy gani sera inachagua kwa URL unayohitaji, si proxy gani shirika linamiliki. Kanuni za PAC zinaweza kurudisha matokeo tofauti kwa huduma za ndani, tovuti za umma na hali za kubadilisha wakati wa hitilafu, na kanuni inayolingana na URL yako leo inaweza kulingana na nyingine baada ya uhariri.

Ikiwa mtiririko wa kazi unahitaji zaidi ya ombi moja linalojulikana, tumia mpangilio tuli unaoungwa mkono na msimamizi au ujumuishaji ulioidhinishwa unaoelewa PAC. Kuweka anwani moja iliyonakiliwa kwa njia ngumu hufanya kazi hadi siku sera inabadilika na hakuna anayekumbuka kwa nini anwani hiyo ilichaguliwa.

Kisha angalia kile curl inarithi. Vigeu vya mazingira vya proxy na NO_PROXY vinaweza kupuuza au kuondoa proxy uliyopitisha, na uondoshaji unaolingana na lengo lako hutuma ombi moja kwa moja kimya kimya. Hifadhi sera iliyokusudiwa badala ya kufuta kila uondoshaji au kulazimisha kila kitu kupitia anwani moja. Endesha ombi mara moja ukiwa na -v na uangalie ni anwani gani iliyounganishwa nayo kwa kweli.

Tenganisha utambulisho mbili wa TLS

Ukiwa na proxy ya HTTPS, miunganisho miwili ya TLS inahusika: yako kwa proxy na ya proxy kwa lengo. Kila moja ina utambulisho wake wa kuthibitisha, na kuzima uthibitishaji kwa yoyote kati yao si suluhisho la PAC, ni tatizo la pili lililoongezwa kwa la kwanza.

Acha uthibitishaji ukiwa umewashwa na usome kushindwa unakopata. Changamoto ya uthibitishaji wa proxy, proxy isiyoweza kufikiwa na kukataliwa na tovuti ni matokeo matatu tofauti, na ya kwanza tu linahusu vitambulisho. VPN bado inapaswa kutoa njia inayoruhusiwa kwa proxy ya kibinafsi, ikiwa ni pamoja na utatuzi wa majina kwa mwenyeji wa proxy yenyewe, kabla ya yoyote ya haya kufanikiwa.

Andika kituo cha mwisho, mpango, bandari, njia ya uthibitishaji, uondoshaji na njia ya VPN hadi proxy. Rekodi hiyo ndiyo inayofanya ombi lijalo liweze kutolewa tena, na ndiyo tofauti kati ya kuijua proxy yako na kuikisia.