ตรวจสอบต้นทางเพื่อแก้ไขปัญหา Nginx 502 ของ ONLYOFFICE

เริ่มต้นด้วยการตรวจสอบการเชื่อมต่อระหว่าง Nginx และ ONLYOFFICE Docs จากนั้นอ่านบันทึกข้อผิดพลาดที่ตรงกับข้อความตอบกลับ 502 ข้อความ 502 Bad Gateway หมายความว่าเกตเวย์ไม่สามารถรับการตอบสนองที่ถูกต้องจากเซิร์ฟเวอร์ต้นทางได้ ซึ่งไม่ได้พิสูจน์ว่าการกำหนดค่า Nginx สาธารณะเป็นสาเหตุโดยตรง ใน Docker วิธีแก้ไขทั่วไปคือการตั้งค่า Nginx ให้เชื่อมต่อกับชื่อบริการ Document Server บนพอร์ตภายใน 80 และตรวจสอบให้แน่ใจว่าคอนเทนเนอร์ทั้งสองใช้เครือข่ายเดียวกัน

คุณควรตรวจสอบอะไรบ้างก่อนแก้ไข Nginx?

รีเวิร์สพร็อกซีคือเซิร์ฟเวอร์ที่รับคำขอจากไคลเอ็นต์และส่งต่อไปยังเซิร์ฟเวอร์อื่น ในการใช้งานทั่วไป Nginx สาธารณะจะจัดการ HTTPS และส่งต่อคำขอไปยัง ONLYOFFICE Docs ผ่าน HTTP นอกจากนี้ ONLYOFFICE Docs ยังใช้งาน Nginx ภายในของตัวเองด้วย ดังนั้นหน้า 502 อาจเกิดจากพร็อกซีภายนอกหรือคอนเทนเนอร์ของเซิร์ฟเวอร์เอกสารเอง

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

docker ps --filter name=onlyoffice-documentserver
docker logs --tail 100 onlyoffice-documentserver

หากคอนเทนเนอร์กำลังรีสตาร์ทหรือเพิ่งเริ่มต้น โปรดตรวจสอบบันทึกก่อนเปลี่ยนการตั้งค่าพร็อกซี ONLYOFFICE ระบุว่าการเริ่มต้นครั้งแรกอาจใช้เวลาหนึ่งหรือสองนาทีในขณะที่ฐานข้อมูลกำลังเริ่มต้น สำหรับการติดตั้งบน Linux ดั้งเดิม โปรดตรวจสอบds-docserviceและds-converterด้วย คำสั่งต่อไปนี้ systemctl statusบันทึกของ Document Server จะอยู่ภายใต้/var/log/onlyoffice/documentserver/.

หากบริการหยุดทำงาน ให้ ใช้ คำแนะนำการแก้ไขปัญหาอย่างเป็นทางการของ ONLYOFFICE สำหรับ Linuxที่ตรงกัน

Nginx สามารถเชื่อมต่อกับ Document Server ที่อยู่ต้นทางได้หรือไม่?

ทดสอบจากคอนเทนเนอร์ Nginx หรือโฮสต์ ไม่ใช่แค่จากแล็ปท็อปของคุณเท่านั้น คอนเทนเนอร์บนเครือข่าย Docker ที่แยกจากกันไม่สามารถระบุชื่อบริการของกันและกันได้ แม้ว่าทั้งสองจะทำงานอยู่ก็ตาม เมื่อ Nginx และ ONLYOFFICE ใช้เครือข่าย Docker ที่ผู้ใช้กำหนดร่วมกัน ให้ใช้ชื่อบริการ Compose หรือชื่อคอนเทนเนอร์ที่สามารถระบุได้ และพอร์ตการฟังของคอนเทนเนอร์ คู่มือการติดตั้ง Docker อย่างเป็นทางการระบุว่าพอร์ต 80 เป็นพอร์ตการฟัง Document Server เริ่มต้น พอร์ตโฮสต์ที่เผยแพร่ เช่น 8080:80 จะไม่เปลี่ยนแปลงพอร์ตภายใน

จากคอนเทนเนอร์พร็อกซี ให้รันคำสั่ง:

curl -I http://onlyoffice-documentserver:80/

แทนที่onlyoffice-documentserverด้วยชื่อบริการ Compose จริงของคุณ หากคำขอระบุว่า “ไม่สามารถแก้ไขโฮสต์ได้” ให้เชื่อมต่อคอนเทนเนอร์ทั้งสองเข้ากับเครือข่าย Docker เดียวกัน หรือแก้ไขชื่ออัปสตรีม “การเชื่อมต่อถูกปฏิเสธ” โดยปกติหมายความว่าโฮสต์เป้าหมายได้รับการแก้ไขแล้ว แต่ไม่มีอะไรยอมรับการเชื่อมต่อบนพอร์ตนั้น คอนเทนเนอร์ยังไม่พร้อม หรือใช้พอร์ตผิด หากเป็นการติดตั้งแบบเนทีฟ ให้ทดสอบที่อยู่ภายในเครื่องและพอร์ตที่กำหนดค่าไว้แทน ตัวอย่างcurl -I http://127.0.0.1/เช่น

คู่มือ Docker ของ ONLYOFFICE ครอบคลุมถึงพอร์ตเริ่มต้น การแมปพอร์ต ความล่าช้าในการเริ่มต้น และบันทึกคอนเทนเนอร์: การติดตั้งและการตรวจสอบ Docker

จะแก้ไขเป้าหมายพร็อกซีของ Nginx อย่างไร?

ในการตั้งค่าโฮสต์เสมือน HTTPS สำหรับชื่อโฮสต์ ONLYOFFICE ให้proxy_passชี้ไปยังอัปสตรีมที่สามารถเข้าถึงได้ ตัวอย่างนี้สมมติว่าใช้เครือข่าย Docker ที่ใช้ร่วมกันและชื่อบริการที่แสดงด้านบน โปรดเปลี่ยนให้ตรงกับการใช้งานของคุณ:

location / {
    proxy_pass http://onlyoffice-documentserver:80;
    proxy_http_version 1.1;
    proxy_set_header Host $host;
    proxy_set_header X-Forwarded-Host $host;
    proxy_set_header X-Forwarded-Proto $scheme;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection "upgrade";
}

อย่าใช้พร็อกซีแบบคอนเทนเนอร์ชี้ ไปยังที่อยู่โฮสต์ที่ 127.0.0.1:8080เข้าถึงไม่ได้ เว้นแต่ว่า Document Server จะกำลังทำงานอยู่ในคอนเทนเนอร์เดียวกัน หรือที่อยู่โฮสต์นั้นได้รับการกำหนดค่าและสามารถเข้าถึงได้โดยตั้งใจ ภายในคอนเทนเนอร์127.0.0.1หมายถึงตัวคอนเทนเนอร์เอง นอกจากนี้ ควรหลีกเลี่ยงการส่ง HTTPS ไปยังเซิร์ฟเวอร์ต้นทางเมื่อปลายทางของ Document Server เป็นเพียง HTTP เท่านั้น

โปรโตคอลและโฮสต์ที่ส่งต่อจะบอก ONLYOFFICE ว่าไคลเอ็นต์ใช้ URL สาธารณะใด และส่วนหัวการอัปเกรดจะอนุญาตการเชื่อมต่อ WebSocket ที่ใช้สำหรับการสื่อสารกับตัวแก้ไขแบบเรียลไทม์ ONLYOFFICE มีตัวอย่างที่ได้รับการดูแลรักษาสำหรับการใช้งาน Docs ผ่านพร็อกซีรวมถึงการกำหนดค่า Nginx HTTPS-to-HTTPด้วย เปรียบเทียบกับตัวอย่างฉบับเต็มหากสภาพแวดล้อมของคุณมีพร็อกซีหลายตัวหรือใช้คำนำหน้าเส้นทาง URL

ก่อนทำการเปลี่ยนแปลงใดๆ โปรดตรวจสอบความถูกต้องของการกำหนดค่าด้วยคำสั่ง `npm run config` nginx -tจากนั้นรีโหลด Nginx โดยใช้วิธีการสำหรับโฮสต์หรือคอนเทนเนอร์ของคุณ อย่ารีสตาร์ททุกบริการพร้อมกัน การรีโหลดแบบค่อยเป็นค่อยไปจะช่วยให้เห็นได้ง่ายขึ้นว่าการแก้ไขจากต้นทางได้เปลี่ยนแปลงผลลัพธ์หรือไม่

ถ้า ONLYOFFICE ยังคงแสดงข้อผิดพลาด 502 ล่ะ?

หากพร็อกซีภายนอกสามารถเข้าถึงหน้าต้อนรับของ Document Server ได้ แต่/healthcheckส่งคืนรหัส 502 ปัญหาอาจอยู่ที่ภายใน Document Server เอง ไม่ใช่ที่ Nginx สาธารณะ ตรวจสอบบันทึกคอนเทนเนอร์ของ Document Server และบันทึกบริการภายใน สำหรับการติดตั้งบน Linux ดั้งเดิม ให้ตรวจสอบคำสั่งสถานะบริการและไดเร็กทอรีบันทึกด้านบน หากหน้า/welcome/ต้อนรับตอบสนอง แต่การตรวจสอบสถานะไม่ทำงาน ให้ถือว่าเป็นสัญญาณที่แยกจากกัน: หน้าต้อนรับแบบคงที่ไม่ได้พิสูจน์ว่าบริการเอกสารและส่วนประกอบที่เกี่ยวข้องทำงานได้อย่างปกติ

อย่า "แก้ไข" ปัญหานี้ด้วยการปิดใช้งาน JWT การตรวจสอบความถูกต้องของ JSON Web Token (JWT) จะตรวจสอบความถูกต้องของคำขอการเชื่อมต่อ การไม่ตรงกันของ JWT มักทำให้เกิดข้อผิดพลาดในการอนุญาต ไม่ใช่ความไม่สามารถเชื่อมต่อกับเซิร์ฟเวอร์ต้นทางในระดับเครือข่าย ตรวจสอบการตั้งค่า JWT เฉพาะในกรณีที่พร็อกซีตอบสนอง แต่การเชื่อมต่อรายงานข้อผิดพลาดในการอนุญาตหรือโทเค็น

สุดท้าย ตรวจสอบให้แน่ใจว่า Nginx กำลังกำหนดเส้นทางชื่อโฮสต์ที่ถูกต้องไปยังโฮสต์เสมือนที่ถูกต้อง การพิมพ์ผิดในserver_nameชื่อ DNS ต้นทาง หรือพอร์ต อาจทำให้ทราฟฟิกถูกส่งไปยังที่อื่น หรือทำให้พร็อกซีใช้การกำหนดค่าที่ล้าสมัย ตรวจสอบบันทึกข้อผิดพลาดของ Nginx สำหรับบรรทัดเช่นhost not found in upstream, connect() failed, หรือupstream timed out; แต่ละบรรทัดชี้ไปยังเลเยอร์ที่แตกต่างกัน

คุณจะตรวจสอบความถูกต้องของการแก้ไขได้อย่างไร?

ทดสอบการเชื่อมต่อต้นทางจากเครือข่ายพร็อกซีอีกครั้ง จากนั้นตรวจสอบจุดเชื่อมต่อด้านสาธารณสุข และเปิดเอกสารผ่านแพลตฟอร์มที่เชื่อมต่ออยู่:

curl -I https://docs.example.com/healthcheck

การตรวจสอบสถานะระบบควรแสดงผลว่าไม่ใช่ 502 อีกต่อไป และเอกสารควรเปิดขึ้นและเชื่อมต่อได้อย่างต่อเนื่องขณะแก้ไข หากการทดสอบต้นทางสำเร็จ แต่การร้องขอสาธารณะยังคงล้มเหลว ให้มุ่งเน้นไปที่โฮสต์เสมือน Nginx ที่เลือก การกำหนดค่าที่โหลด และบันทึกต่างๆ หากหน้าต้อนรับสาธารณะทำงานได้ แต่การตรวจสอบสถานะระบบยังคงเป็น 502 ให้ดำเนินการวินิจฉัยบริการภายในของ ONLYOFFICE ต่อไป

สำหรับพฤติกรรมของคำสั่ง Nginx โปรดดูเอกสารประกอบโมดูลพร็อกซี Nginxอย่างเป็นทางการ คำสั่งและชื่อบริการที่ใช้จริงอาจแตกต่างกันไปตามโปรเจ็กต์ Docker Compose, การแจกจ่าย Linux และเวอร์ชัน ONLYOFFICE ดังนั้นโปรดแทนที่ด้วยชื่อจริงของคุณและตรวจสอบบันทึกจากส่วนประกอบที่สร้างการตอบสนองนั้น