curl ର --preproxy ବିକଳ୍ପ HTTP କିମ୍ବା HTTPS proxy ପାଖରେ ପହଞ୍ଚିବା ପୂର୍ବରୁ SOCKS proxy ସହ ଯୋଗ କରେ। ଏହା ଏହି ନିର୍ଦ୍ଦିଷ୍ଟ ଶୃଙ୍ଖଳ ସମର୍ଥନ କରେ, proxy server ର ଯେକୌଣସି ଇଚ୍ଛାମତ ତାଲିକା ନୁହେଁ।

ପଥ ହେଉଛି client → SOCKS endpoint → HTTP proxy → ଲକ୍ଷ୍ୟ। କମାଣ୍ଡର ଉଭୟ ଦଲିଲ ଉଦାହରଣ endpoint ବଦଳାନ୍ତୁ:

curl --preproxy socks5h://203.0.113.10:1080 --proxy http://203.0.113.20:8080 --noproxy '' --connect-timeout 5 --max-time 20 --verbose https://example.com/

SOCKS ସେବା HTTP proxy ର ଠିକଣା ଓ ପୋର୍ଟକୁ ପହଞ୍ଚିପାରିବା ଦରକାର। ତା'ପରେ HTTP proxy ଲକ୍ଷ୍ୟ ଅନୁରୋଧ ଗ୍ରହଣ କରିବା ଦରକାର। ଦ୍ୱିତୀୟ proxy hostname ବ୍ୟବହାର କଲେ ପ୍ରଥମ SOCKS mode ସେହି ନାମ କେଉଁଠି resolve ହୁଏ ନିର୍ଦ୍ଧାରଣ କରେ; ସଂଖ୍ୟାତ୍ମକ endpoint ଏହି ଖୋଜ ଏଡ଼ାଏ।

ବିଫଳ ପର୍ଯ୍ୟାୟ ଖୋଜିବା

ପ୍ରଥମେ ପ୍ରତ୍ୟେକ endpoint ଦେଇ ଅନୁରୋଧ ପୃଥକ୍ ନିଶ୍ଚିତ କରନ୍ତୁ; HTTP ପର୍ଯ୍ୟାୟ ପାଇଁ ସମୟ ସୀମାଯୁକ୍ତ HTTP proxy ପରୀକ୍ଷା ବ୍ୟବହାର କରନ୍ତୁ। ଉଭୟ କାମ କଲେ ମଧ୍ୟ ପ୍ରଥମ proxy ଦ୍ୱିତୀୟ ପାଖରେ ପହଞ୍ଚି ନ ପାରିବାରୁ ମିଶ୍ରିତ ପଥ ବିଫଳ ହୋଇପାରେ।

ବିସ୍ତୃତ trace ସଂଯୋଗର କ୍ରମରେ ପଢ଼ନ୍ତୁ। ଦ୍ୱିତୀୟ proxy ପାଖରେ ପହଞ୍ଚିବାବେଳର SOCKS ବିଫଳତା HTTP proxy ୱେବସାଇଟ୍‌କୁ CONNECT ଗ୍ରହଣ ବା ପ୍ରତ୍ୟାଖ୍ୟାନ କରିବା ନିଷ୍ପତ୍ତି ପୂର୍ବରୁ ହୁଏ। କେଉଁ handshake ବିଫଳ ହେଲା ଲେଖନ୍ତୁ।

ଅତିରିକ୍ତ ପର୍ଯ୍ୟାୟ କେବେ ସାହାଯ୍ୟ କରେ

ଅନୁମୋଦିତ HTTP proxy କୁ SOCKS ପଥରେ ପହଞ୍ଚିହେଲେ ଏହି ବ୍ୟବସ୍ଥା ଉପଯୋଗୀ ହୋଇପାରେ। କିନ୍ତୁ ଏହା ଅନ୍ୟ ଏକ ସେବା ଓ ନେଟୱର୍କ ପଥ ମଧ୍ୟ ଯୋଡ଼େ ଯାହା ବିଫଳ ହୋଇପାରେ ବା ବିଳମ୍ବ ବଢ଼ାଇପାରେ। ସାର୍ବଜନୀନ proxy ତାଲିକାର endpoint ଶୃଙ୍ଖଳ କଲେ ନିର୍ଭରଯୋଗ୍ୟତା ବା ପରିଚୟ ଗୋପନର ନିଶ୍ଚୟତା ମିଳେ ନାହିଁ ଏବଂ ସଂଯୋଗ ସମ୍ଭାଳୁଥିବା ପକ୍ଷଙ୍କୁ ଏବେ ମଧ୍ୟ ବିଶ୍ୱାସ କରିବାକୁ ହୁଏ।

--preproxy ପାଇଁ curl 7.52.0 ବା ନୂଆ ଦରକାର; ଅନ୍ୟ application ସମାନ ବ୍ୟବସ୍ଥା ସମର୍ଥନ ନ କରିପାରେ।

ସମ୍ପର୍କିତ ପ୍ରବନ୍ଧ