แก้ไขปัญหาการตัดการเชื่อมต่อระหว่างการแก้ไขเอกสาร CODE หลังจาก 10 นาที

หากเอกสาร Collabora Online Development Edition (CODE) เปิดได้ตามปกติ การแก้ไขทำงานได้ และจากนั้นตัวแก้ไขตัดการเชื่อมต่อหลังจากผ่านไปประมาณ 10 นาที ให้เริ่มตรวจสอบเส้นทางการเชื่อมต่อ WebSocket ระหว่างเบราว์เซอร์และ CODE การตัดการเชื่อมต่อที่เกิดขึ้นซ้ำๆ ทุกๆ 600 วินาที บ่งชี้ว่าอาจเป็นปัญหาจาก reverse proxy, ingress controller, load balancer หรือ firewall timeout มากกว่าตัวจับเวลาการทำงานที่ไม่ได้ใช้งานตามค่าเริ่มต้นของ CODE ที่ระบุไว้

ความแตกต่างนี้มีความสำคัญ เพราะการเปลี่ยนการตั้งค่าการไม่ได้ใช้งานของ CODE ก่อน อาจซ่อนปัญหาที่แท้จริงโดยไม่แก้ไขการเชื่อมต่อที่ส่งข้อมูลการแก้ไข เอกสารแม่แบบการกำหนดค่า Collabora ปัจจุบันระบุเวลาหมดอายุการไม่ได้ใช้งานต่อการดู 15 นาที และเวลาหมดอายุเอกสารที่ไม่ได้ใช้งาน 1 ชั่วโมง ไม่ใช่การจำกัดเซสชันการแก้ไข 10 นาที ดูแม่แบบ coolwsd.xml ต้นทาง หากผู้ใช้กำลังพิมพ์อยู่เมื่อการตัดการเชื่อมต่อเกิดขึ้น การตั้งค่า CODE เฉพาะเมื่อไม่ได้ใช้งานก็เป็นคำอธิบายที่อ่อนลงไปอีก

การตัดการเชื่อมต่อ 10 นาทีโดยทั่วไปหมายความว่าอย่างไร

ตรวจสอบแล้ว:ตัวอย่าง Nginx ที่เผยแพร่โดย Collabora ใช้ส่วนหัวการอัปเกรด WebSocket และค่า long proxy_read_timeout 36000sสำหรับ WebSocket หลัก Nginx เองได้ระบุไว้ว่าการเชื่อมต่อ WebSocket ที่ถูกพร็อกซีจะถูกปิดเมื่อไม่ได้รับข้อมูลภายในระยะเวลาหมดเวลาการอ่านที่กำหนดไว้ ซึ่งproxy_read_timeoutค่าเริ่มต้นทั่วไปคือ 60 วินาที ดูคู่มือ SDK ออนไลน์ของ Collaboraและเอกสารประกอบพร็อกซี WebSocket ของ Nginx

ขึ้นอยู่กับสภาพแวดล้อม:การตั้งค่าหมดเวลา 600 วินาทีอาจเกิดขึ้นได้จากเลเยอร์พร็อกซีที่แตกต่างกัน แม้ว่าโฮสต์ Nginx ที่อยู่ด้านหน้า CODE จะดูถูกต้องก็ตาม สถานที่ที่พบได้บ่อย ได้แก่ Kubernetes Ingress, HAProxy, โหลดบาลานเซอร์บนคลาวด์, WAF หรือรีเวิร์สพร็อกซีต้นทาง ระยะเวลาหมดเวลาและคีย์การกำหนดค่าที่แน่นอนจะขึ้นอยู่กับส่วนประกอบนั้นๆ

อาการที่ปรากฏเพียงอย่างเดียวไม่สามารถพิสูจน์ได้: “การตัดการเชื่อมต่อหลังจาก 10 นาที” ไม่ได้หมายความว่า Nginx เป็นส่วนประกอบที่รับผิดชอบ ควรบันทึกการเชื่อมต่อ WebSocket ที่ล้มเหลวและเปรียบเทียบเวลาที่เกิดขึ้นกับบันทึกของพร็อกซีและบันทึก CODE ก่อนที่จะเปลี่ยนแปลงหลายส่วนพร้อมกัน

วิธีแก้ไข:จำลองข้อผิดพลาดโดยเปิดเครื่องมือสำหรับนักพัฒนาของเบราว์เซอร์ และบันทึกระยะเวลาการทำงานของคำขอ WebSocket อย่างละเอียด

ขั้นตอนที่ 1: ยืนยันว่า WebSocket คือสิ่งที่หยุดทำงานจริง ๆ

เปิดเอกสาร จากนั้นเปิดเครื่องมือสำหรับนักพัฒนาของเบราว์เซอร์ แล้วสลับไปที่แผงเครือข่าย กรองหาการรับส่งข้อมูล WebSocket การรับส่งข้อมูลการแก้ไขโค้ดโดยปกติจะมี WebSocket อยู่ภายใต้/cool/เส้นทางนั้น เปิดเอกสารนั้นต่อไปแม้ว่าจะเกิดข้อผิดพลาดขึ้นแล้วก็ตาม

เมื่อการเชื่อมต่อถูกตัด ให้ตรวจสอบคำขอ WebSocket ข้อมูลที่สำคัญที่สุดคือ ระยะเวลา การปิดการเชื่อมต่อ สถานะ HTTP ระหว่างการอัปเกรดครั้งแรก และว่าเบราว์เซอร์รายงานข้อผิดพลาดเครือข่ายหรือไม่ การเริ่มต้นที่ราบรื่น101 Switching Protocolsตามด้วยการปิดการเชื่อมต่อหลังจากประมาณ 600 วินาที บ่งชี้ว่ามีนโยบายอายุการใช้งานการเชื่อมต่อหรือนโยบายการไม่ใช้งานบางอย่างในเส้นทาง การเชื่อมต่อ

หากการอัปเกรด WebSocket ไม่สำเร็จ นี่ไม่ใช่ปัญหา "หมดเวลา 10 นาที" ให้แก้ไขการกำหนดเส้นทางและส่วนหัวของ WebSocket ก่อน หาก WebSocket ยังคงเชื่อมต่ออยู่ขณะที่โปรแกรมแก้ไขแสดงข้อผิดพลาดในการจัดเก็บหรือบันทึก ให้ตรวจสอบเส้นทาง WOPI/การจัดเก็บข้อมูลแทน

ขั้นตอนการดำเนินการ:จดบันทึกเวลาเริ่มต้นและเวลาตัดการเชื่อมต่อ จากนั้นเปรียบเทียบเวลาเหล่านั้นกับบันทึกการเข้าถึง/ข้อผิดพลาดของรีเวิร์สพร็อกซี และบันทึกคอนเทนเนอร์ CODE หรือบันทึกบริการ

ขั้นตอนที่ 2: ตรวจสอบกฎพร็อกซีแบบย้อนกลับของ CODE ก่อนที่จะเปลี่ยนค่าว่างของ CODE

สำหรับ Nginx ส่วนสำคัญคือ ตำแหน่ง WebSocket ต้องส่งผ่านส่วนหัวการอัปเกรดและมีระยะเวลาหมดเวลาในการอ่านที่นานพอสมควร คู่มือ SDK ของ Collabora แสดงรูปแบบนี้สำหรับ WebSocket หลัก:

location ~ ^/cool/(.*)/ws$ {
    proxy_pass https://127.0.0.1:9980;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection "Upgrade";
    proxy_set_header Host $host;
    proxy_read_timeout 36000s;
}

หาก TLS ถูกยกเลิกที่ Nginx และ CODE จงใจให้บริการ HTTP แบบธรรมดาอยู่เบื้องหลัง อาจเป็น scheme ของ upstream http://แทน อย่าคัดลอก scheme โดยไม่ตรวจสอบให้ดี: มันต้องตรงกับวิธีการตั้งค่าของอินสแตนซ์ CODE ของคุณ

ความเข้าใจผิดที่พบบ่อยอย่างหนึ่งคือ การตั้งค่านี้proxy_connect_timeoutควบคุมอายุการใช้งานของเซสชันการแก้ไขที่สร้างขึ้นแล้ว แต่ความจริงไม่ใช่เช่นนั้น การตั้งค่านี้จะมีผลเฉพาะตอนที่กำลังสร้างการเชื่อมต่อกับเซิร์ฟเวอร์ต้นทางเท่านั้น การตั้งค่าที่เกี่ยวข้องโดยตรงกับ WebSocket ที่สร้างขึ้นผ่านพร็อกซีซึ่งมีช่วงเวลาที่ไม่มีข้อมูลจากเซิร์ฟเวอร์ต้นทางคือproxy_read_timeout`true` Nginx ได้อธิบายพฤติกรรมนี้ไว้ในเอกสารอ้างอิงโมดูลพร็อกซี HTTP ของ มัน

ขั้นตอน:ค้นหาบล็อก Nginx ที่ตรงกับ URL WebSocket ของ CODE และยืนยันว่าได้ตั้งค่าหมดเวลาไว้ที่นั่นแล้ว ไม่ใช่ในบล็อกอื่นที่ไม่locationเกี่ยวข้อง

ขั้นตอนที่ 3: พิจารณาการเปลี่ยนแปลงพร็อกซีของ CODE 26.04

ณ เดือนตุลาคม 2026 บันทึกการเผยแพร่ CODE 26.04 ปัจจุบันของ Collabora ระบุว่าเป็น CODE 26.04.4.2 ซึ่งเผยแพร่เมื่อวันที่ 24 กันยายน 2026 ซีรี่ส์ 26.04 ได้นำเสนอ URL WebSocket ที่กระชับยิ่งขึ้น Collabora ระบุว่าการกำหนดค่าพร็อกซีที่มีอยู่แล้วอาจต้องได้รับการอัปเดต ในเวอร์ชัน 26.04 รุ่นต่อๆ ไป CODE อาจกลับไปใช้ URL แบบเดิมและแสดงคำเตือนการตรวจสอบเมื่อพร็อกซีไม่ได้รับการอัปเดต ผู้ใช้ Apache2 ได้รับคำแนะนำเป็นพิเศษให้ทำการอัปเดตกฎ ProxyPass เมื่อมีการเปิดตัว 26.04 โปรดดูบันทึกการเผยแพร่ CODE 26.04 อย่างเป็นทางการ

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

ขั้นตอนการดำเนินการ:ตรวจสอบเวอร์ชัน CODE ของคุณในข้อมูล "เกี่ยวกับผลิตภัณฑ์" หรือแท็กรูปภาพคอนเทนเนอร์ จากนั้นเปรียบเทียบการกำหนดค่าพร็อกซีของคุณกับคำแนะนำพร็อกซีของ Collabora ในปัจจุบัน อย่าคิดว่ากฎที่คัดลอกมาจากเวอร์ชัน 24.04 เก่าจะยังคงเหมาะสมเสมอไป

ขั้นตอนที่ 4: ตรวจสอบ Kubernetes Ingress, HAProxy, Apache และอุปกรณ์กลางอื่นๆ

หาก Nginx เป็นเพียงเลเยอร์เดียวที่อยู่ด้านหน้า CODE การขยายเวลาหมดอายุอาจไม่เพียงพอ สำหรับ Kubernetes ที่ใช้ ingress-nginx เอกสารโครงการได้ระบุคำอธิบายประกอบต่อ Ingress ที่ชื่อว่า `@Ingress-Nginx_annotation_name` nginx.ingress.kubernetes.io/proxy-read-timeoutและ `@Ingress-Nginx_annotation_name` ไว้ คำแนะนำเกี่ยวกับ WebSocket แนะนำให้ใช้ค่าที่มากกว่าหนึ่งชั่วโมงสำหรับการเชื่อมต่อที่มีระยะเวลานาน ดู เอกสารอ้างอิงคำอธิบายประกอบ Ingress-Nginxnginx.ingress.kubernetes.io/proxy-send-timeoutอย่างเป็นทางการและหมายเหตุเกี่ยวกับ WebSocket

metadata:
  annotations:
    nginx.ingress.kubernetes.io/proxy-read-timeout: "3600"
    nginx.ingress.kubernetes.io/proxy-send-timeout: "3600"

สำหรับ HAProxy ตัวอย่าง SDK ของ Collabora ใช้ค่าหมดเวลาการเชื่อมต่อแบบอุโมงค์ที่ยาวนานสำหรับทราฟฟิกแบบ WebSocket สำหรับ Apache ค่าหมดเวลาพร็อกซีทั่วไปจะถูกควบคุมโดยProxyTimeoutแต่ CODE 26.04 ยังต้องการความสนใจในรูปแบบ ProxyPass ของ WebSocket ในปัจจุบันด้วยเอกสาร mod_proxy ของ Apache เอง จะอธิบายถึงสิ่งProxyTimeoutที่ควบคุมค่านี้

ขั้นตอนการดำเนินการ:ลากเส้นทางการเชื่อมต่อจากเบราว์เซอร์ไปยัง CODE และตรวจสอบทุกจุดเชื่อมต่อ การจำกัดเวลา 600 วินาทีที่จุดเชื่อมต่อใดจุดหนึ่งอาจทำให้เซสชันถูกยุติได้

ขั้นตอนที่ 5: ตรวจสอบและโหลดพร็อกซีใหม่อย่างปลอดภัย

หลังจากแก้ไขการตั้งค่า Nginx แล้ว โปรดทดสอบก่อนรีโหลด:

sudo nginx -t
sudo systemctl reload nginx

หาก Nginx ทำงานอยู่ภายในคอนเทนเนอร์ ให้ใช้ขั้นตอนการตรวจสอบและการรีโหลดที่เหมาะสมกับคอนเทนเนอร์แทนที่จะสันนิษฐานว่าsystemctlมีอยู่แล้ว ส่วนสำคัญคือการตรวจสอบไวยากรณ์ก่อนที่จะแทนที่การกำหนดค่าที่กำลังทำงานอยู่

ขั้นตอนการดำเนินการ:เปลี่ยนทีละชั้น บันทึกค่าก่อนหน้า ตรวจสอบความถูกต้องของการตั้งค่า แล้วทดสอบขั้นตอนการทำงานของเอกสารเดิมอีกครั้ง

ขั้นตอนที่ 6: พิสูจน์การแก้ไขด้วยการทดสอบที่ยาวกว่าระยะเวลาตัดขอบเดิม

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

ผลลัพธ์ที่ดีมีสามสัญญาณ ได้แก่ การเชื่อมต่อ WebSocket ยังคงใช้งานได้นานกว่า 10 นาที โปรแกรมแก้ไขยังคงยอมรับการแก้ไขโดยไม่ต้องแจ้งให้เชื่อมต่อใหม่ และไม่มีข้อความหมดเวลาปรากฏในบันทึกของตัวกลางหรือบันทึก CODE

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

ขั้นตอนการดำเนินการ:ตรวจสอบหาองค์ประกอบที่ส่งสัญญาณปิดหรือหมดเวลาต่อไปเรื่อยๆ จนกว่าจะพบองค์ประกอบนั้น

อย่าสับสนระหว่างตัวจับเวลาการไม่ได้ใช้งานของ CODE กับการตัดการเชื่อมต่อเครือข่าย 10 นาที

เทมเพลตการกำหนดค่า CODE ต้นทางในปัจจุบันระบุper_view.idle_timeout_secsไว้ที่ 900 วินาที หรือ 15 นาที คำอธิบายระบุว่ามุมมองจะมืดลงและการอัปเดตจะหยุดลงเมื่อผู้ใช้ไม่ใช้งาน ค่าเริ่มต้นระดับเอกสารidle_timeout_secsคือ 3600 วินาที หรือหนึ่งชั่วโมง ก่อนที่เอกสารที่ไม่ได้ใช้งานจะถูกปิดลง

ค่าเหล่านั้นควรค่าแก่การตรวจสอบหากพฤติกรรมของคุณตรงกับค่าเหล่านั้น แต่ค่าเริ่มต้นทั้งสองค่าไม่ได้อธิบายถึงการตัดการเชื่อมต่อ 600 วินาทีอย่างแม่นยำ หากก่อนหน้านี้มีคนปรับแต่งcoolwsd.xmlตัวแปรสภาพแวดล้อม ค่า Helm หรือพารามิเตอร์คอนเทนเนอร์ การใช้งานของคุณอาจแตกต่างจากค่าเริ่มต้น

ขั้นตอนการดำเนินการ:ตรวจสอบการตั้งค่า CODE ที่มีผลบังคับใช้ก็ต่อเมื่อคุณได้ระบุแล้วว่าความล้มเหลวนั้นเกิดจากระดับเครือข่ายหรือระดับแอปพลิเคชัน อย่าเพิ่มค่าที่ไม่ได้ใช้งานทุกค่าเป็นการตอบสนองแรก

ตารางการวินิจฉัยอย่างรวดเร็ว

สรุปแล้ว

สำหรับการแก้ไขโค้ดที่ตัดการเชื่อมต่อหลังจาก 10 นาทีอย่างสม่ำเสมอ ลำดับขั้นตอนที่มีประสิทธิภาพที่สุดคือ: ยืนยันความล้มเหลวของ WebSocket ตรวจสอบกฎ reverse-proxy ที่ตรงกัน ตรวจสอบการหมดเวลาของตัวกลางทุกตัว พิจารณาการเปลี่ยนแปลง proxy-path ของ CODE 26.04 โหลดใหม่อย่างปลอดภัย และทดสอบเกินเวลาตัดขอบเดิม เปลี่ยนการตั้งค่าการทำงานของ CODE ในโหมดไม่ได้ใช้งานเฉพาะเมื่อพฤติกรรมที่สังเกตได้และการกำหนดค่าที่มีประสิทธิภาพชี้ไปในทิศทางนั้นจริงๆ

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