สคริปต์ติดตามราคาตรวจหน้าสินค้าหลายร้อยหน้าทุกคืนได้ดีหลายเดือน พอเพิ่มความถี่และร้านที่สอง บันทึกก็เต็มไปด้วย 429 และ CAPTCHA คำแนะนำในฟอรัมคือใช้พร็อกซีหมุนเวียน แนวคิดว่า IP มากขึ้นทำให้ถูกบล็อกน้อยลงนั้นถูกเพียงครึ่งเดียว
พร็อกซีส่งคำขอผ่าน IP ที่เปลี่ยนไปหลังเกตเวย์คงที่ เพื่อกระจายทราฟฟิกให้ต่ำกว่าขีดจำกัดต่อ IP แต่ที่อยู่อาจเปลี่ยนระหว่างเข้าสู่ระบบ ทำให้เซสชันที่ยืนยันตัวตนแล้วสะดุด จึงแก้ปัญหาหนึ่งและสร้างอีกปัญหา
เวอร์ชันสั้น
- พร็อกซีหมุนเวียนมีเกตเวย์เดียวพร้อมโฮสต์และพอร์ต ส่งผ่าน IP จากพูล โดยกฎกำหนดเวลาที่เปลี่ยน
- เปลี่ยนทุกคำขอเหมาะกับงานไร้สถานะ เช่น ดึงหน้าสาธารณะ ส่วนการเข้าสู่ระบบและตะกร้าควรใช้เซสชันคงที่หรือพร็อกซีคงที่ โดยเฉพาะเมื่อเว็บไซต์ตรวจความต่อเนื่องของ IP
- แม้หมุนเวียนถูกต้องก็อาจล้มเหลว เพราะลูกค้าคนอื่นทำให้ชื่อเสียง IP ร่วมลดลง ความใหม่ต่อเป้าหมายและการแชร์น้อยสำคัญกว่าขนาดพูล
- การเปลี่ยน IP ไม่ช่วยขีดจำกัดตามบัญชี โทเค็น หรือคุกกี้ งานเล็กควรลดความเร็วและทำตามเวลารอใน
Retry-Afterก่อน
พร็อกซีหมุนเวียนคืออะไร?
เกตเวย์ส่งคำขอผ่าน IP ที่เลือก กฎเปลี่ยนตามคำขอ เวลา หรือเซสชัน โฮสต์และพอร์ตเหมือนเดิม เกตเวย์เลือกที่อยู่ที่เป้าหมายเห็น
ติดตามคำขอหนึ่งรายการ:
- ไคลเอนต์ส่งไปยังโฮสต์และพอร์ตเดิมเสมอ
- เกตเวย์ใช้กฎและเลือก IP ขาออก
- คำขอออกจาก IP นั้นไปยังเว็บไซต์เป้าหมาย
- เป้าหมายเห็น IP ขาออก ที่อยู่ของคุณถูกซ่อน เว้นแต่เกตเวย์ส่งต่อด้วยส่วนหัว เช่น
X-Forwarded-For
ผู้ให้บริการดูแลพูล การตรวจสถานะ และการสลับเมื่อขัดข้อง สคริปต์รู้เพียงโฮสต์และพอร์ต ความสะดวกนี้อธิบายบริการดังกล่าว แต่ตั้งพร็อกซีเองไม่ได้การหมุนเวียนฟรี โดยทั่วไปมีเพียงIP ขาออกคงที่หนึ่งที่อยู่ ส่วนที่จ่ายเงินคือการดูแลพูล
ผู้ขายเรียกเกตเวย์รวมพูลว่า backconnect proxy คู่มือเซิร์ฟเวอร์พร็อกซีของ MDN ใช้คำว่าเกตเวย์เป็นชื่อที่ง่ายกว่าของ forward proxy ประเภท IP แบบที่พักอาศัย ศูนย์ข้อมูล หรือมือถือ แยกจากความถี่ในการเปลี่ยน
อะไรเป็นตัวกำหนดเวลาเปลี่ยน IP?
ขึ้นกับกฎและผู้ให้บริการ เช่น ทุกคำขอ ทุกการเชื่อมต่อ ช่วงเวลาคงที่ หรือคำสั่งโดยตรง ไคลเอนต์หรือตัวจัดการอาจเปลี่ยนก่อนลองคำขอที่ล้มเหลวหรือถูกบล็อกซ้ำ ตรวจความหมายของ ‘ทุกคำขอ’ เพราะ HTTPS หลายคำขออาจใช้อุโมงค์และ IP เดียวกัน เกตเวย์ที่ส่ง HTTPS เข้ารหัสปกติอ่านรหัสตอบกลับเพื่อเริ่มเปลี่ยนเองไม่ได้
| ตัวกระตุ้น | สิ่งที่ต้องแลก |
|---|---|
| ทุกคำขอ | เน้นกระจายมากกว่าต่อเนื่อง การค้นหาและผลหน้าสองอาจใช้คนละ IP |
| ทุก N คำขอ | รวมคำขอ แต่ตัวนับอาจเปลี่ยนระหว่างขั้นสามกับสี่ของกระบวนการห้าขั้น |
| ตามเวลา | คง IP ช่วงหนึ่งแล้วเปลี่ยนเมื่อหมดเวลา แม้อยู่กลางงาน |
| เมื่อล้มเหลว | ลองคำขอที่ถูกบล็อกหรือ 429 ด้วย IP ใหม่ ทนข้อผิดพลาดขึ้น แต่อาจใช้ที่อยู่หมดเงียบ ๆ หากเป้าหมายปฏิเสธทั้งหมด |
ตารางคือการจัดสรร การกระจายทำให้แต่ละ IP ต่ำกว่าเกณฑ์ ความต่อเนื่องช่วยจำผู้เยี่ยมชม การเปลี่ยนทุกคำขอเน้นการกระจายทั้งหมด การเปลี่ยนเมื่อผิดพลาดดูเป็นทางสายกลางที่ทนทาน แต่ซ่อนต้นทุน บันทึกแสดงว่าลองซ้ำสำเร็จจนไม่มีอะไรผ่าน เซสชันคงที่กลับด้านการแลกเปลี่ยน โดยถือ IP เดียวตามช่วงเวลา
เซสชันคงที่ต่างจากการหมุนเวียนและพร็อกซีคงที่อย่างไร?
เซสชันคงที่จอง IP ชั่วคราวให้คำขอดูเป็นผู้เยี่ยมชมคนเดียวแล้วคืน พร็อกซีคงที่ให้ IP เดิมตราบที่ใช้งาน การเปลี่ยนทุกคำขอไม่จองอะไร เลือกตามว่าเว็บไซต์ต้องจำคุณระหว่างคำขอหรือไม่
| ฟีเจอร์ | เปลี่ยนทุกคำขอ | เซสชันคงที่ | พร็อกซีคงที่ |
|---|---|---|---|
| เวลาเปลี่ยน IP | ทุกคำขอหรือการเชื่อมต่อ ตามผู้ให้บริการ | หมดช่วงเวลา จบเซสชัน หรือขาออกขัดข้อง | ปกติคงที่ขณะได้รับจัดสรร |
| เซสชันอยู่ต่อหรือไม่? | อาจล้มเหลวเมื่อมีการตรวจ IP ต่อเนื่อง | อาจอยู่ต่อขณะ IP เดิม แต่ไม่รับประกัน | อาจอยู่ต่อ แต่ยังมีการตรวจอื่น |
| การกระจายคำขอ | ทั่วทั้งพูล | หนึ่ง IP ต่อเซสชัน หลายเซสชันขนานกัน | ทั้งหมดผ่าน IP เดียว |
| เหมาะกับ | ดึงหน้าสาธารณะโดยไม่เก็บสถานะ | หลายขั้นตอนที่ต้องต่อเนื่องหลายนาที | งานบัญชีที่ต้องใช้ตัวตนเดิมหลายวัน |
| ความเสี่ยงหลัก | รบกวนงานที่มีสถานะ | ช่วงสั้นทำให้เซสชันจบกลางงาน | IP เดียวรับทุกขีดจำกัดและการบล็อก |
งานไร้สถานะมักใช้การเปลี่ยนทุกคำขอ งานเข้าสู่ระบบเหลือสองวิธีถือ IP โดยเลือกระยะเวลา เซสชันยืมแล้วคืน ส่วนพร็อกซีคงที่ยังได้รับจัดสรร เข้าจากที่อยู่เดิมทุกวันดูเป็นผู้ใช้เก่า เปรียบเทียบช่วงของผู้ให้บริการกับงานที่ยาวที่สุด ตรวจกรณีขัดข้องด้วย บางรายเปลี่ยนก่อนเวลา แต่โหมด IP เดียวแบบเข้มงวดทำให้คำขอล้มเหลว ช่วงยาวอย่างเดียวไม่รับประกันความต่อเนื่อง
การเปลี่ยน IP ทำให้งานเสียเมื่อใด?
เปลี่ยนกลางการเข้าสู่ระบบ 2FA ตะกร้า ชำระเงิน หรือฟอร์มหลายขั้นอาจสะดุด คุกกี้ไม่ได้หมดอายุอัตโนมัติ แต่เว็บที่ผูกเซสชันกับ IP หรือตรวจเครือข่ายเพื่อกันทุจริตอาจให้ออกจากระบบ ตรวจใหม่ หรือทำเครื่องหมาย
มองว่าเว็บทำหน้าที่ ไม่ได้เจาะจงพร็อกซี คุกกี้อ้างว่าเป็นเบราว์เซอร์เมื่อหนึ่งนาทีก่อน IP เป็นหลักฐานตรวจได้ การเปลี่ยนเครือข่ายระหว่างเซสชันที่ยืนยันแล้วดูเหมือนนำคุกกี้ขโมยไปใช้ที่อื่น ซึ่งระบบป้องกันทุจริตต้องจับ การออกจากระบบและ 2FA จึงสมเหตุสมผล
แนวทางจัดการเซสชันของ OWASP อธิบายการตรวจการเปลี่ยน IP และ User-Agent ตามมาตรการเว็บ ความเปลี่ยนแปลงผิดคาดอาจเตือนหรือยุติเซสชัน
เว็บต้องจำคุณระหว่างคำขอหรือไม่? ถ้าใช่ให้ถือ IP เดียว ไม่เช่นนั้นหมุนเวียนได้ ตรวจราคาสาธารณะกลางคืนไม่ต้อง แต่เข้าสู่แดชบอร์ดเพื่อส่งออกรายงานต้องใช้ IP เดียวตั้งแต่ต้นจนจบ
เคล็ดลับ: แยกงานผสม พูลหมุนเวียนสำหรับข้อมูลไร้สถานะ IP แบบเซสชันคงที่หรือคงที่สำหรับเข้าสู่ระบบและงานที่ยืนยันแล้ว ความต้องการตรงข้ามไม่ควรใช้กฎเดียว
ทำไมพูลหยุดทำงานหลังไม่กี่วัน?
แม้หมุนเวียนถูกก็พังได้ เพราะเปลี่ยน IP ไม่ใช่ชื่อเสียง ที่อยู่ร่วมสืบทอดกิจกรรมเดิม ใช้กับเป้าหมายเดิมหนัก ๆ อาจถูกทำเครื่องหมายและสำเร็จน้อยลง
พูลเป็นทรัพยากรร่วมจำกัด ลูกค้าแต่ละรายใช้ชื่อเสียงกับเว็บไซต์ หากคนอื่นใช้ IP เดียวกันกับเป้าหมายคุณ คุณจ่ายด้วย CAPTCHA และการบล็อก ในงานสนับสนุนพบว่าชื่อเสียงเป็นระบบนิเวศเว็บไซต์และรายการบล็อกที่ตอบสนองต่อสิ่งที่พบจากที่อยู่
ขนาดโฆษณาง่ายแต่ทำนายได้น้อยกว่าที่คิด ผลขึ้นกับ:
- ใช้กับเป้าหมายเดียวล่าสุดเมื่อใด ที่อยู่ซึ่งลูกค้าอื่นใช้หนึ่งชั่วโมงก่อนถูกนับแล้ว
- จำนวนผู้แชร์ งานมากทำให้เสื่อมเร็ว
- ความหลากหลายเครือข่าย IP กระจุกในไม่กี่ช่วงอาจถูกบล็อกพร้อมกัน
- ถูกทำเครื่องหมายแล้วหรือไม่ พูลที่เก็บ IP ถูกมองว่าใช้งานผิดยังแจกต่อ
พูลใหญ่ใช้ซ้ำมากอาจด้อยกว่าพูลเล็กที่ IP ใหม่สำหรับเป้าหมายคุณ เปรียบเทียบผลตามเวลา การทดสอบแรกผ่านไม่พิสูจน์ประสิทธิภาพระยะยาว
จำเป็นต้องใช้พร็อกซีหมุนเวียนหรือไม่?
อาจกระจายภายใต้ขีดจำกัด IP แต่ไม่แทนการทำตามขีดจำกัดและคำสั่งลองซ้ำ ตามเอกสาร 429 ของ MDN ปกติจำกัดตาม IP แต่อาจตามผู้ใช้หรือแอปเมื่อยืนยันตัวตนหรือมีคุกกี้ ขีดจำกัดบัญชีไม่สน IP ใหม่ งานเล็กควรทำตาม Retry-After ก่อน
มาตรฐานคือ RFC 6585 ซึ่งกำหนดรหัส 429 อนุญาต Retry-After บอกเวลารอ โดยไม่กำหนดวิธีระบุผู้ใช้หรือนับ ตัวอย่างระบุข้อมูลยืนยันตัวตนหรือคุกกี้ที่มีสถานะ
สามกรณีไม่ควรซื้อ: จำกัดตามบัญชี โทเค็น API หรือคุกกี้ ซึ่งทุก IP ใช้โควตาเดียวและยัง 429; งานเล็กที่กระจายหลายร้อยหน้าต่อคืน รอ Retry-After และลองซ้ำด้วยเวลารอเพิ่มแบบเอ็กซ์โพเนนเชียลได้ฟรี; งานเข้าสู่ระบบที่ต้องการตัวตนและ IP คงที่
เหมาะเมื่อจำกัดตาม IP คุณค่าขึ้นกับปริมาณ และแต่ละคำขออิสระภายในขอบเขตที่อนุญาต เงื่อนไขเว็บไซต์ยังใช้บังคับ เว็บดูตัวตนไคลเอนต์ระดับการเชื่อมต่อและจังหวะคำขอด้วย การเปลี่ยนอย่างเดียวไม่รับประกันเข้าถึง
ก่อนจ่าย อ่านเอกสารและส่วนหัว หากคำขอที่ยืนยันแล้วแบบเทียบเคียงได้ 429 แต่ไม่ยืนยันจาก IP เดียวสำเร็จ เป็นเพียงสัญญาณของขีดจำกัดบัญชีหรือการยืนยัน ไม่ใช่ข้อพิสูจน์ ทั้งคู่ล้มเหลวอาจจำกัดตาม IP ทรัพยากร หรือทั้งเซิร์ฟเวอร์ ใช้ปลายทางและอัตราเทียบกันได้ และทำตาม Retry-After ก่อนทดสอบใหม่
คำถามที่พบบ่อย
เหมือน VPN หรือไม่?
ไม่ VPN มักส่งทราฟฟิกทั้งเครื่องผ่านอุโมงค์เข้ารหัสไปเซิร์ฟเวอร์เดียว และคง IP ระหว่างเชื่อมต่อ พร็อกซีตั้งตามแอปหรือคำขอ เปลี่ยนตามกฎ สคริปต์เดียวจึงใช้หลาย IP ได้
ทำให้ไม่เปิดเผยตัวตนหรือไม่?
ไม่ทั้งหมด ซ่อน IP จากเป้าหมาย ไม่ใช่ผู้ให้บริการที่เห็นที่อยู่และเว็บไซต์ เมื่อเข้าสู่ระบบหรือส่งคุกกี้เก็บไว้ เว็บรู้บัญชีหรือคุกกี้ไม่ว่า IP ใด
เว็บไซต์บล็อกได้หรือไม่?
ได้ การบล็อกทีละ IP อาจไม่ได้ผล ดังที่ผู้ดูแลในกระทู้ Hacker News เรื่องเว็บถูกทำสำเนาผ่านพร็อกซีพบ เพราะ IP ต้นทางเปลี่ยน คำตอบเสนอให้บล็อกเครือข่ายและช่วงทั้งหมด เว็บยังใช้ WAF ประเมินรูปแบบคำขอ เพิ่มได้
ควรเปลี่ยนบ่อยแค่ไหน?
ไม่มีช่วงสากล ขึ้นกับขีดจำกัดต่อ IP ของแต่ละเป้าหมาย งานไร้สถานะเปลี่ยนเท่าที่จำเป็น ในเซสชันที่ต้องอยู่ต่อ เช่น เข้าสู่ระบบหรือชำระเงิน ห้ามเปลี่ยน
การสนทนา
ความคิดเห็น
เข้าสู่ระบบเพื่อร่วมสนทนา