પ્રોક્સી બ્રાઉઝરનું IP બદલે છે, બીજી ઍપનું કેમ નહીં?
બ્રાઉઝર અથવા Wi-Fiની HTTP પ્રોક્સી સેટિંગ દરેક ઍપ અને પ્રોટોકોલને પસંદ કરેલા IPમાંથી આપમેળે પસાર કરતી નથી.
બ્રાઉઝરમાં બદલાયેલું IP એ જ બ્રાઉઝરની વિનંતી વિશે કહે છે. બીજી ઍપ સીધો માર્ગ રાખી શકે છે, કારણ કે દરેક ક્લાયન્ટે પ્રોક્સી સેટિંગને ટેકો આપવો અને વાપરવી પડે છે.
| પ્રોક્સી ક્યાં સેટ કરી | સામાન્ય રીતે શું નિયંત્રિત કરે |
|---|---|
| Firefoxની મેન્યુઅલ સેટિંગ | Firefoxથી સમર્થિત વિનંતીઓ. |
| સિસ્ટમ HTTP પ્રોક્સી | તે કનફિગરેશન વાંચતી અને સમર્થન આપતી ઍપ. |
| ઍપના HTTP અથવા SOCKS વિકલ્પ | તે ઍપના અમલીકરણમાં આવતો ટ્રાફિક. |
| Wi-Fi નેટવર્કની પ્રોક્સી | તે નેટવર્ક પર સેટિંગ વાપરતા ક્લાયન્ટ. |
રમત કે વૉઇસ કૉલ HTTP માર્ગની બહારનો ટ્રાફિક વાપરી શકે છે; સીધા સૉકેટ ખોલતી ઍપ સિસ્ટમ પ્રોક્સીને સંપૂર્ણ અવગણી શકે છે. SOCKS5ને પણ અમલીકરણનો ટેકો જોઈએ: પ્રોટોકોલ UDP association નક્કી કરે છે, પરંતુ Chromiumનું બિલ્ટ-ઇન SOCKS5 સમર્થન TCP URL વિનંતીઓ માટે છે, સામાન્ય UDP relay નહીં.
બીજી ઍપનું દસ્તાવેજ ધરાવતું પ્રોક્સી ઇન્ટરફેસ શોધીને તેનો પ્રોટોકોલ મેળવો. તે ન હોય તો સિસ્ટમ HTTP એન્ડપૉઇન્ટ વારંવાર બદલવાથી કદાચ ઍપ કનફિગર નહીં થાય. ઍપની વિનંતી તેના ડાયગ્નૉસ્ટિક્સ અથવા તમારા નિયંત્રણના ગંતવ્યથી તપાસો; curl એન્ડપૉઇન્ટ ચકાસી શકે, બીજી ઍપનો માર્ગ પ્રમાણિત નહીં કરી શકે.
શરૂ કર્યા પછી કે નેટવર્ક બદલાય ત્યારે ફરી તપાસો. પ્રક્રિયા શરૂઆતમાં વાંચેલી સેટિંગ રાખી શકે છે, અને મોબાઇલ ડેટા પર જતો ફોન Wi-Fiનું ખાસ કનફિગરેશન પાછળ છોડી દે છે. આખા ઉપકરણનું રૂટિંગ જોઈએ તો તે વિસ્તાર માટે બનાવેલો ઉપાય પસંદ કરો; એક ક્લાયન્ટની HTTP સેટિંગ તે સ્થાપી શકતી નથી.