เบราว์เซอร์โหลดหน้า HTTP ผ่าน Squid ปลายทางเดียวกันล้มเหลวภายใต้ proxychains นั่นไม่ได้หมายความว่าหนึ่งในสองโปรแกรมเลือก IP พร็อกซีผิด

ไคลเอนต์ทั่วไปที่เข้าใจ HTTP สามารถส่งคำขอเว็บไปยังพร็อกซีขาหน้าในรูปแบบ HTTP proxy ส่วนตัวห่อ socket ทั่วไปนั้นต้องใช้อุโมงค์ไบต์สำหรับการเชื่อมต่อที่แอปพลิเคชันต้องการเปิด proxychains ใช้ CONNECT สำหรับพร็อกซี HTTP ในสายของตน

นั่นหมายความว่าเว็บไซต์ข้อความธรรมดาบนพอร์ต 80 สามารถสร้างคำขอ CONNECT สำหรับพอร์ต 80 ได้ นโยบายของ Squid ที่อนุญาต CONNECT ไปยังรายการพอร์ต TLS ที่อนุมัติเท่านั้นอาจปฏิเสธอุโมงค์นั้น ทั้งที่คำขอ HTTP ปกติไปยังพอร์ต 80 ได้รับอนุญาต

เปรียบเทียบคำขอ ไม่ใช่แค่ชื่อโฮสต์

เอกสารของ proxychains-ng อธิบายการรองรับ HTTP CONNECT กฎการเข้าถึงของ Squid แยกวิธีและพอร์ตปลายทางได้ นี่คือเส้นทางคำขอที่ต่างกันไปยังเว็บไซต์เดียวกัน

อ่านเหตุผลการปฏิเสธและนโยบายที่ตั้งใจก่อนจะเปลี่ยนมัน การขยายการเข้าถึง CONNECT ไปทุกพอร์ตเป็นการเปลี่ยนแปลงครั้งใหญ่ ไม่ควรเป็นคำตอบเริ่มต้นสำหรับความไม่สอดคล้องของตัวห่อ

หากแอปพลิเคชันรองรับ HTTP proxy แบบเนทีฟ การใช้มันสามารถหลีกเลี่ยงอุโมงค์ทั่วไปที่ไม่จำเป็นสำหรับ HTTP แบบข้อความธรรมดา หากต้องการอุโมงค์ TCP ดิบจริง ๆ ให้เลือกโปรโตคอลพร็อกซีและนโยบายพอร์ตที่ได้รับอนุมัติซึ่งมีให้

คำขอจากเบราว์เซอร์ที่สำเร็จเป็นหลักฐานที่มีประโยชน์เกี่ยวกับการเข้าถึงพร็อกซีและโหมดคำขอหนึ่งที่รองรับ แต่ไม่ได้พิสูจน์ว่าทุกวิธีทำอุโมงค์ พอร์ตปลายทาง หรือโปรโตคอลแอปพลิเคชันได้รับอนุญาตผ่านพร็อกซีนั้น

บทความที่เกี่ยวข้อง