પ્રોક્સી નિષ્ફળ થાય ત્યારે શું OkHttp સીધું જ કનેક્ટ થશે?
નિષ્ફળ પ્રોક્સી સીધા ઍક્સેસ તરફ દોરી શકે કે નહીં તે નક્કી કરવા ક્લાયંટ સંસ્કરણ, રાઉટિંગ ઉમેદવારો અને ઍપ્લિકેશનના ફરી પ્રયાસ માર્ગનો ઉપયોગ કરો.
સિસ્ટમ-HTTP-પ્રોક્સીના ઐતિહાસિક કિસ્સામાં OkHttp એ 3.5.0 માં તેનું વર્તન બદલ્યું: તે પ્રોક્સી નિષ્ફળ ગયા પછી સીધું કનેક્શન અજમાવવાનું બંધ કર્યું. શાંત પાછા ફરવાનો જૂનો અહેવાલ તે પરિવર્તન પહેલાંના વર્તનનું વર્ણન કરી શકે છે.
તે ઇતિહાસ દરેક ઍપ્લિકેશનની રાઉટિંગ નીતિ નક્કી કરતો નથી. તમારી પોતાની ઍપ્લિકેશનમાંથી આવેલા અહેવાલનું અર્થઘટન કરવા આ ત્રણ તપાસો અનુસરો:
- નિર્ધારિત OkHttp સંસ્કરણ શોધો. નકલ કરાયેલા ઉદાહરણની ઉંમરને બદલે ઍપ્લિકેશનની નિર્ભરતા માહિતી વાપરો, જેમાં ફ્રેમવર્ક ખરેખર બંડલ કરે તે સંસ્કરણનો સમાવેશ થાય છે.
- આ ક્લાયંટ કેવી રીતે રૂટ પસંદ કરે છે તે શોધો. સ્પષ્ટ પ્રોક્સી અને કસ્ટમ ProxySelector જુદી જુદી ગોઠવણીઓ છે. જો પસંદગીકર્તા પ્રોક્સી પછી સીધો ઉમેદવાર આપે, તો તે સીધો વિકલ્પ આપી રહ્યો છે.
- નિષ્ફળતા હેન્ડલર અનુસરો. બીજા ક્લાયંટ સાથે ફરી પ્રયાસ કરતો ઍપ્લિકેશન કોડ શોધો. તે બદલીદાર દ્વારા કરાયેલી સીધી વિનંતી પ્રથમ ક્લાયંટના નિર્ણયની બહાર છે.
ફરજિયાત-પ્રોક્સી જરૂરિયાત માટે સંબંધિત ક્લાયંટ નીતિએ સીધો વિકલ્પ આપવાને બદલે થોભવું જોઈએ. વાસ્તવિક ક્લાયંટ અને ફરી પ્રયાસ માર્ગને તે જરૂરિયાત સામે તપાસો; ફક્ત 3.5.0 પરિવર્તન આખી મશીન માટેનો ટ્રાફિક નિયમ નથી.