ପ୍ରକ୍ସି ବ୍ରାଉଜର୍ର 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 ସେଟିଂ ତାହା କରିପାରିବ ନାହିଁ।