curl ستاسو PAC فایل نشي لوستلی: پرځای یې proxy ولیږدئ
PAC د JavaScript پالیسي ده؛ curl پای ټکی غواړي. وپوښتئ پالیسي ستاسو URL لپاره کوم proxy ټاکي، هغه ولیږدئ او NO_PROXY او TLS ته پام وکړئ.
په کانفیګ فایل کې د PAC فایل پته او د proxy پای ټکی د یو بل پرځای د کارېدو وړ ښکاري، خو نه دي. یو د پالیسۍ پروګرام دی چې د هر URL لپاره باید ارزول شي؛ بل هغه هوسټ او پورټ دی چې اړیکې مني. curl یوازې دویم پېژني. PAC پته --proxy ته سپارل د کټګورۍ تېروتنه ده چې په ګډوډه توګه ناکامېږي، معمولاً د ویب سرور ته د اوږد CONNECT وخت تېرېدو وروسته.
هر یو واقعاً څه دی
| تاسو لرئ | هغه څه دی | curl ورسره څه کوي |
|---|---|---|
http://wpad.corp.example/proxy.pac | JavaScript چې د ټاکل شوي URL لپاره proxy یا مستقیمه اړیکه بېرته راګرځوي | هغه د فایل په توګه را اخلي او هم هلته درېږي |
http://proxy.corp.example:8080 | اورېدونکی چې د proxy له لارې راغلې غوښتنې مني | هغه کاروي، د HTTPS هدفونو لپاره CONNECT هم په کې |
دا په روښانه توګه وایي د curl په اړه ډېرې پوښتل شوې پوښتنې: curl د JavaScript یا PAC هېڅ تفسیر نه وړاندې کوي. د curl شاوخوا د PAC پوهېدونکی پوښ کولای شي، خو خود curl نه، او هېڅ فلګ هغه براوزر نه جوړوي.
ولې براوزر کار کوي او curl نه
براوزر د سیستم د proxy ترتیب سره یوځای کېږي، PAC فایل را اخلي او خپل قواعد د هغه URL پر وړاندې چلوي چې تاسو یې خلاصوئ. همغه ارزونه هغه خدمت دی چې PAC فایل یې وړاندې کوي، او له براوزر دننه، نه ستاسو په ټرمینل کې پېښېږي.
PAC فایل د curl سره ډاونلوډ کول یوازې د هغه متن راوړي. دا curl ته پالیسي نه پلي کوي، او د proxy موندلو لپاره یې په لاس لوستل د همغې ارزونې لاسي نسخه ده، د غلطې څانګې د ټاکلو همغه چانس سره. که یې لوستئ، د فایل په لومړي proxy نوم پسې د خپل هوسټ سره سمون لرونکې return جمله ولولئ. ډېری PAC فایلونه څو لري، او یوازې یوه څانګه ستاسو لپاره تطبیقېږي.
د منل شوي HTTP proxy او منل شوې HTTPS خدمت لپاره، یوه بېلګه غوښتنه دا ده:
curl --proxy http://proxy.corp.example:8080 https://service.example.net/statusلومړی پته د proxy اورېدونکی دی، دویمه هغه خدمت دی چې تاسو یې غواړئ. دا بېلګې پای ټکي دي نه هغه ازموینه چې چا کړې، نو هغه د خپل سازمان سکیم، پورټ او تصدیق بهیر سره بدل کړئ.
دې منزل لپاره proxy وټاکئ
له مدیر څخه پوښتنه وکړئ چې پالیسي ستاسو لپاره اړین URL کې کوم proxy ټاکي، نه دا چې سازمان کوم proxy لري. PAC قواعد د داخلي خدمتونو، عامه سایټونو او د ناکامۍ د بدلون حالتونو لپاره بېلابېل پایلې کولای شي، او کوم قاعده چې نن ستاسو URL سره سمه ده، کېدای شي د سمون وروسته له بلې سره سمه شي.
که کاري بهیر له یوې زیاتې پېژندل شوې غوښتنې ته اړتیا ولري، د مدیر ملاتړ شوی ثابت ترتیب یا منل شوې PAC پوهېدونکې مدغمېدنه وکاروئ. یوه کاپي شوې پته په کلکه کوډ کول تر هغې ورځې کار کوي چې پالیسي بدله شي او هېڅوک نه یادېږي چې هغه پته ولې ټاکل شوې وه.
بیا وګورئ curl څه میراث ترلاسه کوي. د proxy چاپېریال متغیرونه او NO_PROXY کولای شي هغه proxy چې تاسو سپارلی، له پامه وغورځوي یا یې وباسي، او د ستاسو د هدف سره سمون لرونکې استثنا غوښتنه په خاموشۍ سیده لېږي. هر استثنا ړنګول یا هر څه د یوې پتې له لارې تېرول پرېږدئ او پام کې ساتل شوې پالیسي وساتئ. غوښتنه یو ځل -v سره چل کړئ او وګورئ چې واقعاً له کومې پتې سره وصل شوه.
دوه TLS پېژندنې جلا وساتئ
له HTTPS proxy سره، دوه TLS اړیکې په لوبې کې دي: ستاسو proxy ته او د proxy هدف ته. هر یو خپله پېژندنه لري چې باید تصدیق شي، او د دوی له یوې لپاره تصدیق بندول د PAC سمون نه دی، بلکې دویمه ستونزه ده چې لومړنۍ ته ورزیاته شوې ده.
تصدیق پرانیستی وساتئ او هغه ناکامي ولولئ چې درته راځي. د proxy تصدیق ننګونه، نارسېدونکی proxy او د وېبسایټ انکار درې بېلابېلې پایلې دي، او یوازې لومړۍ د اعتبارنامو په اړه ده. VPN لاهم باید شخصي proxy ته اجازه شوې لار برابره کړي، په کې د proxy هوسټ لپاره د نوم حلولو سره، مخکې له دې چې له دې څخه څه بریالي شي.
پای ټکی، سکیم، پورټ، د تصدیق طریقه، استثناوې او proxy ته د VPN لار ولیکئ. همغه ریکارډ بلې غوښتنې ته د بیا تولید وړتیا ورکوي، او ستاسو د proxy پېژندلو او په اړه یې اټکل کولو ترمنځ توپیر هم همغه دی.