curl તમારી PAC ફાઇલ વાંચી શકતું નથી: તેના બદલે પ્રોક્સી પાસ કરો
PAC એ JavaScript નીતિ છે; curl ને એન્ડપોઇન્ટ જોઈએ છે. પૂછો કે નીતિ તમારા URL માટે કઈ પ્રોક્સી પસંદ કરે છે, તે પાસ કરો અને NO_PROXY તથા TLS પર ધ્યાન રાખો.
કન્ફિગ ફાઇલમાં PAC ફાઇલનું સરનામું અને પ્રોક્સી એન્ડપોઇન્ટ એકબીજાના બદલે વપરાય તેવા લાગે છે, પણ એવું નથી. એક નીતિ પ્રોગ્રામ છે જે દરેક URL માટે મૂલ્યાંકન કરવો પડે; બીજું એ હોસ્ટ અને પોર્ટ છે જે કનેક્શન સ્વીકારે છે. curl ફક્ત બીજાને સમજે છે. PAC સરનામું --proxy ને પાસ કરવું એ શ્રેણીની ભૂલ છે જે ગૂંચવણભરી રીતે નિષ્ફળ જાય છે, સામાન્ય રીતે વેબ સર્વર તરફ લાંબા CONNECT ટાઇમઆઉટ પછી.
દરેક ખરેખર શું છે
| તમારી પાસે | તે શું છે | curl તેની સાથે શું કરે છે |
|---|---|---|
http://wpad.corp.example/proxy.pac | JavaScript જે આપેલ URL માટે પ્રોક્સી અથવા સીધું કનેક્શન પરત આપે છે | તેને ફાઇલ તરીકે ડાઉનલોડ કરે છે અને ત્યાં જ અટકે છે |
http://proxy.corp.example:8080 | એક લિસનર જે પ્રોક્સી થયેલી વિનંતીઓ સ્વીકારે છે | તેનો ઉપયોગ કરે છે, HTTPS લક્ષ્યો માટે CONNECT સહિત |
તે સ્પષ્ટ કહે છે curl અંગેના સામાન્ય પ્રશ્નો: curl JavaScript કે PAC નું કોઈ અર્થઘટન આપતું નથી. curl ની આસપાસનું PAC સમજતું આવરણ એ કરી શકે, પણ curl પોતે નહીં, અને કોઈ ફ્લેગ તેને બ્રાઉઝર બનાવતો નથી.
બ્રાઉઝર કેમ કામ કરે છે અને curl કેમ નહીં
બ્રાઉઝર સિસ્ટમની પ્રોક્સી ગોઠવણી સાથે જોડાય છે, PAC ફાઇલ મેળવે છે અને તમે ખોલો છો તે URL સામે તેના નિયમો ચલાવે છે. એ મૂલ્યાંકન એ જ સેવા છે જે PAC ફાઇલ આપે છે, અને તે તમારા ટર્મિનલમાં નહીં, બ્રાઉઝરની અંદર થાય છે.
curl સાથે PAC ફાઇલ ડાઉનલોડ કરવાથી ફક્ત તેનું ટેક્સ્ટ મળે છે. તે curl ને નીતિ અમલમાં મૂકવા મજબૂર કરતું નથી, અને પ્રોક્સી શોધવા માટે તેને હાથે વાંચવું એ જ મૂલ્યાંકનનું હાથે કરેલું સંસ્કરણ છે, ખોટી શાખા પસંદ કરવાની એ જ શક્યતા સાથે. જો તમે તેને વાંચો, તો ફાઇલમાંના પહેલા પ્રોક્સી નામને બદલે તમારા હોસ્ટ સાથે મેળ ખાતું return વિધાન વાંચો. મોટાભાગની PAC ફાઇલોમાં ઘણા હોય છે, અને ફક્ત એક જ શાખા તમને લાગુ પડે છે.
મંજૂર HTTP પ્રોક્સી અને મંજૂર HTTPS સેવા માટે, એક ઉદાહરણરૂપ વિનંતી આ છે:
curl --proxy http://proxy.corp.example:8080 https://service.example.net/statusપહેલું સરનામું પ્રોક્સી લિસનર છે, બીજું તમે ઈચ્છો તે સેવા છે. આ ઉદાહરણ એન્ડપોઇન્ટ છે, કોઈએ કરેલી કસોટી નહીં, તેથી તેમને તમારી સંસ્થાની સ્કીમ, પોર્ટ અને પ્રમાણીકરણ પ્રવાહ સાથે બદલો.
આ ગંતવ્ય માટે પ્રોક્સી પસંદ કરો
વ્યવસ્થાપકને પૂછો કે નીતિ તમને જરૂરી URL માટે કઈ પ્રોક્સી પસંદ કરે છે, સંસ્થા પાસે કઈ પ્રોક્સી છે તે નહીં. PAC નિયમો આંતરિક સેવાઓ, જાહેર સાઇટો અને નિષ્ફળતા-ફેરબદલીની સ્થિતિઓ માટે જુદા જુદા પરિણામો આપી શકે છે, અને આજે તમારા URL સાથે મેળ ખાતો નિયમ સંપાદન પછી બીજા સાથે મેળ ખાઈ શકે છે.
જો કાર્યપ્રવાહને એક કરતાં વધુ જાણીતી વિનંતીની જરૂર હોય, તો વ્યવસ્થાપક-સમર્થિત સ્થિર સેટિંગ અથવા મંજૂર PAC સમજતું એકીકરણ વાપરો. એક નકલ કરેલું સરનામું હાર્ડકોડ કરવું ત્યાં સુધી કામ કરે છે જ્યાં સુધી નીતિ બદલાય અને કોઈને યાદ ન રહે કે એ સરનામું કેમ પસંદ કરાયું હતું.
પછી જુઓ curl શું વારસામાં લે છે. પ્રોક્સી એન્વાયર્નમેન્ટ વેરિયેબલ્સ અને NO_PROXY તમે પાસ કરેલી પ્રોક્સીને ઓવરરાઇડ અથવા બાકાત કરી શકે છે, અને તમારા લક્ષ્ય સાથે મેળ ખાતું બાકાત કરવું વિનંતીને ચૂપચાપ સીધી મોકલે છે. દરેક બાકાતને ભૂંસી નાખવાને બદલે અથવા બધું એક જ સરનામેથી પસાર કરવાને બદલે ઇચ્છિત નીતિ જાળવો. વિનંતી એક વાર -v સાથે ચલાવો અને તપાસો કે તે ખરેખર કયા સરનામે જોડાયું.
બે TLS ઓળખ અલગ રાખો
HTTPS પ્રોક્સી સાથે, બે TLS કનેક્શન ચાલુ છે: તમારું પ્રોક્સી તરફ અને પ્રોક્સીનું ગંતવ્ય તરફ. દરેકની ચકાસવાની પોતાની ઓળખ છે, અને તેમાંથી કોઈ પણ એક માટે ચકાસણી બંધ કરવી એ PAC સુધારો નથી, પહેલી સમસ્યામાં ઉમેરાયેલી બીજી સમસ્યા છે.
ચકાસણી ચાલુ રાખો અને તમને મળતી નિષ્ફળતા વાંચો. પ્રોક્સી પ્રમાણીકરણ પડકાર, પહોંચી ન શકાય તેવી પ્રોક્સી અને વેબસાઇટનો ઇનકાર એ ત્રણ જુદા પરિણામો છે, અને ફક્ત પહેલું જ ઓળખપત્રો સાથે સંબંધિત છે. VPN એ હજી પણ ખાનગી પ્રોક્સી સુધીનો મંજૂર માર્ગ પૂરો પાડવો પડે છે, જેમાં પ્રોક્સી હોસ્ટ માટેના નામ-ઉકેલનો પણ સમાવેશ થાય છે, તે પહેલાં આમાંથી કંઈ પણ સફળ થઈ શકતું નથી.
એન્ડપોઇન્ટ, સ્કીમ, પોર્ટ, પ્રમાણીકરણ પદ્ધતિ, બાકાતો અને પ્રોક્સી સુધીનો VPN માર્ગ લખી રાખો. એ જ રેકોર્ડ આગલી વિનંતીને પુનરુત્પાદનક્ષમ બનાવે છે, અને તમારી પ્રોક્સી જાણવા અને તેના વિશે અનુમાન કરવા વચ્ચેનો આ જ ફરક છે.