libproxy માર્ગ પસંદ કરે છે; તમારો ક્લાયન્ટ જોડાણ કરે છે

જો libproxy પ્રોક્સી URI પરત કરે પણ આગળનું સોકેટ સીધું જોડાય, તો હસ્તાંતરણ તપાસો. libproxy નીતિ શોધે છે; એપ્લિકેશન ખોલે છે તે દરેક સોકેટ તે અટકાવતું નથી.

1. સંસાધન માટે પૂછો. દસ્તાવેજીકૃત libproxy 0.5 C API માં પ્રોક્સી ફેક્ટરી બનાવો અને વાસ્તવિક ગંતવ્ય URL માંગો.
2. ક્રમાંકિત ઉમેદવારોનું અર્થઘટન કરો. HTTP, SOCKS અને સીધા પરિણામોને અલગ હેન્ડલિંગ જોઈએ. તેમનો પ્રાધાન્ય ક્રમ અને ઇચ્છિત નિષ્ફળતા નીતિ જાળવો.
3. ગ્રાહક ગોઠવો. પસંદ કરેલ પ્રોક્સી પ્રકાર, એન્ડપોઇન્ટ અને પ્રમાણીકરણ ગોઠવણી એવા ટ્રાન્સપોર્ટને આપો જે તેમને સમર્થન આપે. કાચું TCP સોકેટ પરત મળેલ URI થી CONNECT કે SOCKS વાટાઘાટ મેળવતું નથી.

એક જ જવાબને બધા ગંતવ્યો માટે માર્ગ તરીકે સાચવશો નહીં અને પ્રથમ પ્રોક્સી એક વાર નિષ્ફળ ગયું તે કારણે સીધું રાઉટિંગ કાયમી ન બનાવો.

જો HTTP ક્લાયન્ટ પહેલેથી સિસ્ટમ પ્રોક્સી કે PAC શોધ સંકલિત કરે છે, તો પસંદગીનો એક જ માલિક પસંદ કરો. બે સ્વતંત્ર પસંદગીકર્તા અને બીજું આવરણ એવો માર્ગ બનાવી શકે છે જે કોઈ પણ નીતિનો ઇરાદો ન હતો.

નેવિટિવ કોડમાં સ્થાપિત API ની ફેક્ટરી અને પરિણામ-મેમરી જીવનચક્ર અનુસરો. ફેક્ટરીનો પુનરુપયોગ ઉપયોગી શોધ સ્થિતિ રાખી શકે છે, પણ તેને હજી પણ દરેક ગંતવ્ય માટે પ્રશ્નની જરૂર છે. પસંદગીને જોડાણના પરિણામથી અલગ લોગ કરો: પરત મળેલ URI સફળ પ્રમાણીકરણ, ઉકેલ કે આગળની પ્રવેશ સિદ્ધ કરતું નથી.