proxy_redirect ไม่ได้เชื่อม NGINX เข้ากับโฮสต์ VPN ของคุณ
proxy_redirect เขียนเฮดเดอร์ในคำตอบที่มาถึงแล้วเท่านั้น ไม่เคยเลือก upstream ตรวจสอบ proxy_pass เส้นทางไปยัง backend แล้วจึงตรวจเฮดเดอร์
ชื่อมีคำว่า redirect จึงถูกนำไปวางในบล็อก location เมื่อไม่สามารถเข้าถึง backend ที่อยู่หลัง VPN ได้ ไม่มีอะไรเปลี่ยนแปลง และข้อสรุปที่ชัดเจนคือคำสั่งนี้เสียหรือต้องการไวยากรณ์อื่น สิ่งที่เกิดขึ้นจริงนั้นเรียบง่ายและไม่น่าภูมิใจนัก: proxy_redirect ทำงานกับคำตอบที่กลับมาแล้วเท่านั้น และในการติดตั้งนี้ไม่มีคำขอใดไปถึงจุดนั้นเลย
สองคำสั่ง สองช่วงเวลาในคำขอเดียว
คำขอ HTTP ผ่านพร็อกซีย้อนกลับต้องผ่านการตัดสินใจหลายอย่างตามลำดับ และคำสั่งทั้งสองอยู่ที่ปลายทั้งสองข้างของลำดับนั้น คำสั่งหนึ่งเลือกว่าคำขอจะไปที่ใด อีกคำสั่งแก้ไขเฮดเดอร์บางตัวในคำตอบที่ส่งกลับมา
| Directive | When it acts | What it can change |
|---|---|---|
proxy_pass | Before any bytes leave the proxy | Which upstream receives the request |
proxy_redirect | After the upstream responds | Matching Location and Refresh text |
ลำดับนั้นคือคำตอบทั้งหมด ถ้าแถวที่สองไม่เคยทำงานเพราะแถวแรกล้มเหลว คำสั่งที่สองไม่ได้กำหนดค่าผิด มันเป็นเพียงสิ่งที่เข้าถึงไม่ได้ ไม่ว่าจะเขียนบรรทัดที่สองใหม่กี่ครั้ง คำตอบที่มันควรแก้ไขก็จะไม่เกิดขึ้น วินิจฉัยจากแถวแรกออกไป แล้วพฤติกรรมที่สับสนจะกลายเป็นเส้นทางที่หายไปหรือการเชื่อมต่อที่ถูกปฏิเสธ
การเลือก upstream เป็นหน้าที่ของ proxy_pass
สมมติว่า NGINX ทำงานบนโฮสต์ทางเข้าสาธารณะและเข้าถึงแอปพลิเคชันที่ 10.40.0.20:8080 ผ่าน VPN ของตน ชิ้นส่วนที่เลือกแอปพลิเคชันนั้นมีลักษณะเช่นนี้ ภายในบล็อก server ที่มีอยู่:
location / {
proxy_pass http://10.40.0.20:8080;
}ใช้สคีม ที่อยู่ และพอร์ตจริง และถือว่านี่เป็นชิ้นส่วนไม่ใช่การติดตั้ง โฮสต์ทางเข้าต้องถือเส้นทาง VPN เส้นทางส่งต่อที่ได้รับอนุญาต และทราฟฟิกตอบกลับที่ทำงานได้ไปยังบริการนั้นด้วย เพราะพร็อกซีที่เข้าถึงที่อยู่บนกระดาษยังต้องได้รับการยอมรับจากเคอร์เนล
เอกสารอ้างอิงของโมดูล proxy แยกการเลือก upstream ออกจากการเขียนเฮดเดอร์ตอบกลับใหม่ และระบุว่าค่า proxy_pass ที่มี URI จะเปลี่ยนวิธีแทนที่คำนำหน้า location ที่ตรงกัน การเพิ่มหรือลบองค์ประกอบเส้นทางโดยไม่ตรวจสอบ URL ที่แอปพลิเคชันคาดหวังเป็นวิธีที่เชื่อถือได้ในการสร้าง 404 ที่ดูเหมือนความล้มเหลวในการกำหนดเส้นทาง
proxy_redirect ซ่อมคำตอบที่รั่วที่อยู่ส่วนตัว
เมื่อทราฟฟิกเริ่มไหล backend อาจตอบด้วยเฮดเดอร์ Location ที่ระบุที่อยู่ส่วนตัวของตน เบราว์เซอร์ที่ตามเฮดเดอร์นั้นจะออกจากจุดเข้าสาธารณะและพยายามเข้าถึงสิ่งที่ไม่สามารถแก้ไขได้ การเขียนคำตอบใหม่ที่กำหนดไว้อย่างตั้งใจจะแมป URL ส่วนตัวไปยัง URL สาธารณะ:
proxy_redirect http://10.40.0.20:8080/ https://app.example.com/;แทนที่ทั้งสองด้านด้วยค่าจริง เข้าใจขอบเขตที่แคบด้วย: ข้อความของเฮดเดอร์ Location และ Refresh ที่ตรงกันจะถูกเขียนใหม่ แต่ URL ที่ฝังอยู่ใน HTML, JavaScript หรือไฟล์ที่ดาวน์โหลดจะไม่ถูกเขียนใหม่
หากแอปพลิเคชันสร้างลิงก์แบบสัมบูรณ์ทุกที่ วิธีแก้ที่ยั่งยืนคือการกำหนดค่า URL ภายนอกของแอปพลิเคชันเอง ไม่ใช่รายการกฎการเขียนใหม่ที่เพิ่มขึ้นบนพร็อกซี การเพิ่มกฎไปเรื่อย ๆ จนผลลัพธ์ดูถูกต้องจะสร้างการกำหนดค่าที่ล้มเหลวในหน้าแรกที่ไม่มีใครทดสอบ การตั้งค่าแอปพลิเคชันที่ถูกต้องเพียงครั้งเดียวแทนที่ทั้งชุด
สิ่งที่การเขียนเฮดเดอร์ใหม่ซ่อมไม่ได้
ปัญหาที่อยู่ใกล้เคียงหลายอย่างดูเหมือนปัญหาการเปลี่ยนเส้นทางแต่ไม่ใช่ เฮดเดอร์ Host ที่ส่งไปยัง upstream อาจต้องตรงกับโฮสต์เสมือนของ backend upstream แบบ TLS อาจต้องใช้ชื่อเซิร์ฟเวอร์เฉพาะและการตรวจสอบใบรับรอง และการเขียนเฮดเดอร์ตอบกลับใหม่ไม่ได้ช่วยทั้งสองอย่าง
ขอบเขตของคุกกี้และแอตทริบิวต์โดเมนเป็นของแอปพลิเคชันและการกำหนดค่าของมัน พร็อกซีสามารถทิ้งหรือเขียนเฮดเดอร์ใหม่ได้ทั้งวันและยังสร้างเซสชันที่ล้มเหลวในคำขอที่สอง เพราะคุกกี้ออกให้กับโฮสต์ที่เบราว์เซอร์ไม่เคยเยี่ยมชม ความล้มเหลวนั้นดูเหมือนเกิดขึ้นเป็นระยะ จึงอยู่รอดได้นานในคิวตั๋ว การอ่านโดเมนของคุกกี้มักจบการสอบสวนภายในหนึ่งนาที
จำกัดการพิสูจน์ตัวตนและการเลือก backend ให้อยู่กับแอปพลิเคชันที่ตั้งใจด้วย พร็อกซีย้อนกลับสาธารณะควรเปิดเผยแอปพลิเคชันเดียวผ่าน VPN ของเซิร์ฟเวอร์ แทนที่จะกลายเป็นประตูทั่วไปสู่ทุกที่อยู่ส่วนตัวที่โฮสต์นั้นเข้าถึงได้ location เดียวแบบทั่วไปที่ส่งต่อทุกสิ่งที่ผู้เรียกขอจะเปลี่ยนบริการที่เปิดเผยหนึ่งบริการให้เป็นแผนที่ของเครือข่ายส่วนตัวของคุณ ระบุชื่อ upstream อย่างชัดเจนและเก็บไว้ที่นั่น
ทดสอบตามลำดับที่คำขอเดินทาง
ยืนยันสามอย่างตามลำดับ: NGINX เลือก location ที่ตั้งใจไว้ สำเร็จคำขอไปยัง backend และเบราว์เซอร์ตามการเปลี่ยนเส้นทางใด ๆ ที่ตามมาและโหลดทรัพยากรย่อย แต่ละขั้นตอนมีบรรทัดล็อกของตัวเอง และการอ่านตามลำดับจะเปลี่ยน 502 ที่คลุมเครือให้เป็นข้อค้นพบที่ชัดเจน
ความแตกต่างที่คุณต้องการคือระหว่างการเชื่อมต่อ upstream ที่ล้มเหลวกับเบราว์เซอร์ที่ถูกส่งไปยังชื่อส่วนตัวที่เข้าถึงไม่ได้ อย่างแรกปรากฏในล็อกข้อผิดพลาดของพร็อกซี อย่างที่สองปรากฏเป็นคำขอที่ไม่เคยมาถึง โดยเบราว์เซอร์บ่นเกี่ยวกับโฮสต์ที่ไม่สามารถแก้ไขได้ สองปัญหาที่แตกต่าง สองไฟล์ที่แตกต่าง และมีเพียงหนึ่งเดียวเท่านั้นที่เกี่ยวข้องกับ proxy_redirect