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

302 บอกว่าไปที่ไหน ไม่ได้บอกว่าทำไม

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

ไม่มีสิ่งใดในนั้นเป็นหลักฐานเกี่ยวกับ VPN อุโมงค์คือเส้นทาง การเปลี่ยนเส้นทางคือคำสั่งที่แอปพลิเคชันเขียนขึ้น

บันทึกห่วงโซ่ ไม่ใช่บรรทัดในล็อก

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

เก็บบันทึกนั้นเป็นส่วนตัว URL มีตัวระบุเซสชัน และไฟล์เก็บถาวรของเบราว์เซอร์ที่บันทึกไว้มีมากกว่าที่คุณคาด ตัดสตริงคิวรีออกก่อนวางสิ่งใดลงในตั๋ว

ความคิดของแอปพลิเคชันเกี่ยวกับ URL ของตัวเอง

Magento สร้าง URL แบบสัมบูรณ์จากการกำหนดค่า โดยมีขอบเขตตามเว็บไซต์หรือมุมมองร้านค้า bin/magento config:show web/secure/base_url พิมพ์ค่าที่แอปพลิเคชันเชื่อ และมักเป็นชื่อโฮสต์ที่ตกค้างจากการสร้างหรือการย้ายข้อมูล ไม่ใช่ชื่อที่เบราว์เซอร์ใช้ หากระบุโฮสต์ภายในไว้ เบราว์เซอร์จะถูกส่งไปที่ที่ไปไม่ถึง และไม่มีการเปลี่ยนแปลงอุโมงค์ใดแก้ไขได้

เปรียบเทียบ URL ฐานแบบปลอดภัยและไม่ปลอดภัยกับชื่อสาธารณะที่อยู่ตรงหน้าคุณ ความไม่ตรงกันในข้อใดข้อหนึ่งจะสร้างการเปลี่ยนเส้นทางที่คุณกำลังจ้องอยู่พอดี

ส่วนหัวพร็อกซีที่เชื่อถือได้คือสัญญา

เมื่อ TLS สิ้นสุดที่ตัวกระจายโหลด แอปพลิเคชันจะเห็น HTTP ธรรมดาและต้องบอกให้รู้เป็นอย่างอื่น การตั้งค่าส่วนหัว offloader ระบุชื่อส่วนหัวที่พร็อกซีตั้ง เช่น โปรโตคอลที่ส่งต่อ และแอปพลิเคชันเชื่อถือส่วนหัวนั้นในการตัดสินใจเรื่องสคีมา

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

เมื่อลูปเป็นเซสชัน ไม่ใช่เส้นทาง

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

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

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