คู่มือเกมแลค › ค้นหาตามอาการ

เข้าเกมไม่ได้/โหลดไม่จบ: 45 สาเหตุและทีมที่ต้องแก้

เรียกอีกอย่างว่า: ล็อกอินไม่ได้, โหลดวนไม่จบ

เปิดพจนานุกรมอาการในฉบับหลักที่มีภาพ →

เข้าไปในเกมไม่ได้ หรือติดอยู่ที่หน้าโหลดหรือหน้าเข้าเกม

ขึ้น “เชื่อมต่อเซิร์ฟเวอร์ไม่ได้” ซ้ำ ๆ หรือเลือกตัวละครแล้วแถบโหลดไม่ไปต่อ

จุดที่รับการเชื่อมต่อใหม่ (คิวรอเชื่อมต่อของเซิร์ฟเวอร์, ไฟร์วอลล์, เซิร์ฟเวอร์ล็อกอิน, DB) เต็ม พบบ่อยเป็นพิเศษทันทีหลังปิดปรับปรุง

สาเหตุที่ทำให้เกิดอาการนี้

L2 OS และอุปกรณ์ฝั่งไคลเอนต์

• โปรแกรมความปลอดภัยตรวจแพ็กเก็ต: ถ้าแอนตี้ไวรัสหรือไฟร์วอลล์ตรวจทุกแพ็กเก็ต ความหน่วงจะเพิ่มขึ้น และถ้าตรวจเข้มเกินไปก็อาจเข้าใจผิดว่าเกมเป็นการโจมตีแล้วบล็อก (ภายนอก (ภายนอก))

L3 เครือข่ายในบ้าน

• เราเตอร์สเปกไม่พอหรือร้อนเกิน: เมื่ออุปกรณ์หลายสิบเครื่องและการเชื่อมต่อหลายพันรายการมารวมที่เราเตอร์ราคาถูก ตัวเราเตอร์เองจะประมวลผลไม่ไหว (ภายนอก (ภายนอก))
• ข้อจำกัดของ Wi-Fi สาธารณะและเครือข่ายบริษัท: หน้าล็อกอิน Wi-Fi ของร้านกาแฟหรือไฟร์วอลล์ของบริษัทบล็อกการเชื่อมต่อของเกม (ภายนอก (ภายนอก))

L4 เส้นทางอินเทอร์เน็ต

• การจำกัด UDP และตรวจแพ็กเก็ตระดับประเทศหรือ ISP: บางเครือข่ายบล็อก IP หรือพอร์ต UDP บางตัว หรือจำกัดความเร็ว UDP และอุปกรณ์ตรวจแพ็กเก็ตจะกรองโปรโตคอลที่ไม่รู้จักทิ้ง เกมที่สื่อสารด้วย UDP จึงเชื่อมต่อในเครือข่ายนั้นไม่ได้หรือหลุดบ่อย (ภายนอก (ภายนอก))
• DNS ขัดข้อง/ช้า: ถ้า DNS ซึ่งแปลงชื่อเซิร์ฟเวอร์เป็น IP ช้าหรือล้มเหลว เกมจะหาเซิร์ฟเวอร์ล็อกอินหรือเซิร์ฟเวอร์แพตช์ไม่เจอ (ภายนอก (ภายนอก))
• ลิงก์ที่ใช้ร่วมกันเต็มเพราะ DDoS: การโจมตีปริมาณมหาศาลที่พุ่งเป้ามาที่บริษัทเกม หรือที่อื่นในเครือข่ายเดียวกัน ทำให้ลิงก์ที่ใช้ร่วมกันเต็ม (อินฟราเครือข่าย (ทีมอินฟรา))
• IP ที่ ISP ให้ใช้ร่วมกัน (CGNAT): เครือข่ายมือถือและ ISP บางรายให้ผู้ใช้บริการหลายรายใช้ IP เดียวร่วมกัน และลบ mapping ของการเชื่อมต่อที่ idle ภายในเวลาสั้น ๆ (พัฒนาไคลเอนต์ (ทีมพัฒนาเกม))
• เชื่อมต่อผ่าน VPN/โปรแกรมลดปิง: เมื่อเปิด VPN หรือโปรแกรมลดปิง แพ็กเก็ตจะวิ่งผ่านเซิร์ฟเวอร์ตัวกลาง (relay) ของบริษัทนั้น ถ้าเซิร์ฟเวอร์ตัวกลางอยู่ไกลหรือแออัด ก็กลับยิ่งช้าลง (ภายนอก (ภายนอก))

L5 อุปกรณ์เครือข่ายในดาต้าเซ็นเตอร์

• ตารางเซสชันของไฟร์วอลล์เต็ม: ไฟร์วอลล์บันทึกทุกการเชื่อมต่อที่ปล่อยผ่านไว้ในตารางเซสชันเพื่อติดตาม เมื่อตารางเต็มก็รับการเชื่อมต่อใหม่ไม่ได้ (อินฟราเครือข่าย (ทีมอินฟรา))
• การอ้อมผ่านระบบป้องกัน DDoS และ false positive: เมื่อเบี่ยงทราฟฟิกไป scrubbing center เพื่อกันการโจมตี เส้นทางจะยาวขึ้น และบางครั้งระบบเข้าใจผิดว่าผู้เล่นปกติเป็นการโจมตีแล้วบล็อก (อินฟราเครือข่าย (ทีมอินฟรา))
• ขีดจำกัดการเชื่อมต่อ/พอร์ตของ NAT gateway บนคลาวด์: การเชื่อมต่อที่เซิร์ฟเวอร์ใน private subnet ออกไปภายนอก (ระบบยืนยันตัวตนของแพลตฟอร์ม, ระบบชำระเงิน, API ภายนอก) จะผ่าน NAT gateway ซึ่งแปลง IP และพอร์ตก่อนส่งออก ถ้าการเชื่อมต่อพร้อมกันไปยังปลายทางเดียวกันเกินขีดจำกัดพอร์ตของ gateway การเชื่อมต่อใหม่จะล้มเหลว (อินฟราเครือข่าย (ทีมอินฟรา))
• โหลดบาลานเซอร์กระจายไม่เท่ากัน/health check ตัดสินผิด: การเชื่อมต่อไปกองที่เซิร์ฟเวอร์เครื่องเดียว หรือยังส่งคนไปเซิร์ฟเวอร์ที่ตายแล้วอยู่เรื่อย ๆ (อินฟราเครือข่าย (ทีมอินฟรา))
• MTU ไม่ตรงกัน (เฉพาะแพ็กเก็ตใหญ่ที่หาย): ถ้า MTU (ขนาดที่ส่งได้ในครั้งเดียว) ของช่วงกลางทางลดลง แต่ข้อความแจ้งว่าขนาดเกินถูกบล็อก แพ็กเก็ตใหญ่จะหายไปเรื่อย ๆ (อินฟราเครือข่าย (ทีมอินฟรา))

L7 OS ของเซิร์ฟเวอร์ (เคอร์เนล)

• คิวรอเชื่อมต่อ (backlog) ล้น: ทันทีหลังปิดปรับปรุง ถ้าผู้เล่นหลายหมื่นคนเชื่อมต่อพร้อมกัน คิวรอเชื่อมต่อ (backlog) ของเคอร์เนลจะล้น และความพยายามเชื่อมต่อจะถูกทิ้ง (พัฒนาเซิร์ฟเวอร์ (ทีมพัฒนาเกม))
• ขีดจำกัด file descriptor: ทุกการเชื่อมต่อต้องใช้ file descriptor (fd คือหมายเลขที่ OS กำหนดให้ไฟล์หรือซ็อกเก็ตที่เปิดอยู่) แต่จำนวน fd ที่หนึ่งโปรเซสเปิดได้มีจำกัด (อินฟราเซิร์ฟเวอร์ (ทีมอินฟรา))
• ตาราง conntrack ของเซิร์ฟเวอร์เต็ม: เมื่อตาราง connection tracking (conntrack) ที่ไฟร์วอลล์ของ Linux ใช้บันทึกทุกการเชื่อมต่อแตะขีดจำกัด แพ็กเก็ตใหม่จะถูกทิ้ง (อินฟราเซิร์ฟเวอร์ (ทีมอินฟรา))
• ephemeral port หมดในการเชื่อมต่อระหว่างเซิร์ฟเวอร์: ถ้าเซิร์ฟเวอร์เกมเปิดและปิดการเชื่อมต่อสั้น ๆ ไปยัง DB หรือเซิร์ฟเวอร์อื่นบ่อย ๆ การเชื่อมต่อที่ปิดแล้วจะยังถือครองพอร์ตอยู่สักพัก จนเปิดการเชื่อมต่อใหม่ไม่ได้ (พัฒนาเซิร์ฟเวอร์ (ทีมพัฒนาเกม))

L8 ซ็อกเก็ตและโปรโตคอล

• keepalive ค่าเริ่มต้น 2 ชั่วโมง: ถ้าอีกฝั่งหายไปโดยไม่ส่งสัญญาณปิด TCP จะรู้ตัวหลังผ่านไปนานมาก keepalive (ฟีเจอร์ของ TCP ที่ตรวจว่าการเชื่อมต่อที่ idle ยังอยู่หรือไม่) ปิดไว้เป็นค่าเริ่มต้น และต่อให้เปิด ก็ต้อง idle ครบ 2 ชั่วโมงก่อนจึงเริ่มตรวจ (พัฒนาเซิร์ฟเวอร์ (ทีมพัฒนาเกม))
• การกระจายของ SO_REUSEPORT ไม่สมดุล: เมื่อหลายโปรเซสแบ่งกันรับพอร์ตเดียวกัน เคอร์เนลจะกำหนดโปรเซสที่รับแต่ละการเชื่อมต่อด้วย hash ของที่อยู่ และไม่เปลี่ยนอีก ถ้าโปรเซสตัวใดหยุด เฉพาะคนที่ถูกจัดให้โปรเซสนั้นจะต้องรอ (พัฒนาเซิร์ฟเวอร์ (ทีมพัฒนาเกม))

L9 โปรเซสเกมฝั่งเซิร์ฟเวอร์

• thread pool หมด: ถ้า worker thread ที่ประมวลผลงานติดอยู่กับงานช้าทั้งหมด คำขอใหม่จะต้องรอไปเรื่อย ๆ อย่างไม่มีกำหนด (พัฒนาเซิร์ฟเวอร์ (ทีมพัฒนาเกม))

L11 ดิสก์

• การเขียน core dump: ตอนเซิร์ฟเวอร์ล่ม ต้องเขียนหน่วยความจำหลาย GB ลงดิสก์ บางครั้งการรีสตาร์ตจึงล่าช้าไปหลายนาที (อินฟราเซิร์ฟเวอร์ (ทีมอินฟรา))

L12 ฐานข้อมูล

• คิวรีที่ไม่มีอินเด็กซ์: ถ้าไม่มีอินเด็กซ์ การหาแถวที่ตรงเงื่อนไขต้องอ่านทั้งตาราง (full table scan) (พัฒนาเซิร์ฟเวอร์ (ทีมพัฒนาเกม))
• connection pool หมด: จำนวนการเชื่อมต่อที่เปิดไว้กับ DB มีจำกัด ถ้าคิวรีที่ช้าถือครองการเชื่อมต่อไว้ คำขอที่เหลือต้องรอ (พัฒนาเซิร์ฟเวอร์ (ทีมพัฒนาเกม))
• cold cache (หลังรีสตาร์ตใหม่ ๆ): เมื่อรีสตาร์ต DB แคชในหน่วยความจำจะว่างเปล่า ช่วงหนึ่งข้อมูลทุกอย่างที่ดึงจึงต้องอ่านจากดิสก์ (อินฟรา DB (ทีมอินฟรา))
• คนแห่ล็อกอินและคิวรี N+1: ถ้าการโหลดตัวละครหนึ่งตัวต้องดึงข้อมูลแยกกันหลายสิบครั้ง ผู้เล่นหลายหมื่นคนที่ล็อกอินพร้อมกันจะกลายเป็นคิวรีหลายล้านคิวรี (พัฒนาเซิร์ฟเวอร์ (ทีมพัฒนาเกม))
• failover ของ DB: ระหว่างที่ DB หลักล่มและสลับไปใช้ DB สำรอง จะเขียนข้อมูลไม่ได้ และข้อมูลช่วงท้ายที่ยัง replicate ไม่ทันอาจหายไป (อินฟรา DB (ทีมอินฟรา))
• แคชสแตมปีด: ถ้าแคชของข้อมูลยอดนิยมหมดอายุพร้อมกัน คำขอหลายพันรายการจะแห่ไปที่ DB พร้อมกัน (พัฒนาเซิร์ฟเวอร์ (ทีมพัฒนาเกม))
• คำสั่ง Redis ที่ช้า: Redis ประมวลผลคำสั่งทีละคำสั่ง คำสั่งที่ช้าเพียงคำสั่งเดียวจึงขวางทุกคำขอที่ตามมา (พัฒนาเซิร์ฟเวอร์ (ทีมพัฒนาเกม))
• คิวรีช้าเพราะ query plan เปลี่ยน: โค้ดเหมือนเดิม แต่ถ้า DB เปลี่ยนวิธีประมวลผลคิวรีเดิม (query plan) คิวรีที่เมื่อวานใช้ 2 ms วันนี้อาจกลายเป็นหลายร้อย ms (อินฟรา DB (ทีมอินฟรา))
• ล็อกจากการเปลี่ยนสคีมา (DDL) ระหว่างให้บริการ: ถ้าเพิ่มคอลัมน์หรืออินเด็กซ์ให้ตารางระหว่างให้บริการ ล็อกที่ต้องใช้เพียงชั่วครู่ตัวเดียวอาจทำให้ทุกคำขอที่ใช้ตารางนั้นต้องรอ (อินฟรา DB (ทีมอินฟรา))

L13 สถาปัตยกรรมเซิร์ฟเวอร์และการดูแลระบบ

• ย้ายโซน (ส่งต่อตัวละครข้ามเซิร์ฟเวอร์): เมื่อเข้าพื้นที่หรือดันเจี้ยนอื่น ขั้นตอนส่งข้อมูลตัวละครไปยังเซิร์ฟเวอร์อื่นทำให้เกิดดีเลย์และความล้มเหลว (พัฒนาเซิร์ฟเวอร์ (ทีมพัฒนาเกม))
• ความล้มเหลวแบบลูกโซ่: เมื่อเซอร์วิสหนึ่งช้าลง เซิร์ฟเวอร์ที่เรียกใช้เซอร์วิสนั้นจะติดอยู่กับการรอคำตอบ จนฟีเจอร์ที่ไม่เกี่ยวข้องก็หยุดทำงานไปด้วย (พัฒนาเซิร์ฟเวอร์ (ทีมพัฒนาเกม))
• เซิร์ฟเวอร์เสริมขัดข้อง: ถ้าเซิร์ฟเวอร์ที่รันแยกจากเซิร์ฟเวอร์เกม เช่น แชต, ปาร์ตี้ หรือตลาดประมูล ขัดข้อง จะใช้งานไม่ได้เฉพาะฟีเจอร์นั้น (พัฒนาเซิร์ฟเวอร์ (ทีมพัฒนาเกม))
• การ deploy และรีสตาร์ต: ถ้ารีสตาร์ตเซิร์ฟเวอร์เพื่ออัปเดตโดยไม่ย้ายการเชื่อมต่อ ผู้เล่นที่อยู่บนเซิร์ฟเวอร์นั้นจะหลุด และการบันทึกข้อมูลก่อนปิดกับการเชื่อมต่อใหม่จะทะลักเข้ามาพร้อมกัน (พัฒนาเซิร์ฟเวอร์ (ทีมพัฒนาเกม))
• autoscaling เพิ่มเครื่องไม่ทัน: เมื่อคนแห่เข้ามา ระบบจะเพิ่มเซิร์ฟเวอร์อัตโนมัติ แต่ต้องใช้เวลาเตรียมหลายนาที และระหว่างนั้นเซิร์ฟเวอร์เดิมรับโหลดเกิน (อินฟราเซิร์ฟเวอร์ (ทีมอินฟรา))
• การพึ่งพาเซอร์วิสภายนอก: ถ้าเซอร์วิสภายนอก เช่น ล็อกอินผ่านแพลตฟอร์ม, การชำระเงิน หรือการยืนยันตัวตน ช้าหรือหยุดทำงาน ผู้เล่นจะติดอยู่ที่ขั้นตอนนั้น (ภายนอก (ภายนอก))
• ใบรับรอง TLS หมดอายุ/ตั้งค่าผิด: ถ้าใบรับรองของเซิร์ฟเวอร์ล็อกอิน, API หรือแพตช์หมดอายุ หรือขาดใบรับรองกลาง (intermediate certificate) ไคลเอนต์ที่เชื่อมต่อใหม่ตั้งแต่วินาทีนั้นจะเชื่อมต่อ TLS ไม่สำเร็จ (อินฟราเครือข่าย (ทีมอินฟรา))
• คิวล็อกอินชนเพดานและ grace period ตอนเชื่อมต่อใหม่ไม่พอ: เมื่อคนแห่เข้ามาทันทีหลังเปิดตัวเกมหรือปิดปรับปรุง คิวล็อกอินจะชนเพดานจนปฏิเสธคนที่จะเข้าคิวใหม่ และผู้เล่นที่รออยู่ถ้าหลุดไปแป๊บเดียวก็เสียลำดับคิวแล้วต้องกลับไปต่อท้าย (พัฒนาเซิร์ฟเวอร์ (ทีมพัฒนาเกม))

การออกแบบการซิงก์

• โปรโตคอลที่ต้องไปกลับตามลำดับหลายรอบ (chatty): ถ้าการกระทำหนึ่งครั้งต้องไปกลับเซิร์ฟเวอร์หลายรอบตามลำดับ ปิงจะคูณตามจำนวนรอบนั้น (พัฒนาเซิร์ฟเวอร์ (ทีมพัฒนาเกม))

ปัญหาที่เกิดกับบางคนเท่านั้น

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

ต้นเหตุของการส่งซ้ำใน TCP

• ไฟร์วอลล์/connection tracking ทิ้งแพ็กเก็ต: ไฟร์วอลล์หรือ connection tracking ของ Linux (conntrack คือฟังก์ชันที่บันทึกการเชื่อมต่อที่ผ่านลงในตาราง) จะทิ้งแพ็กเก็ตเมื่อตารางเต็ม หรือเมื่อตัดสินว่าสถานะการเชื่อมต่อไม่ถูกต้อง (อินฟราเครือข่าย (ทีมอินฟรา))
• MTU black hole (เฉพาะแพ็กเก็ตใหญ่ที่หายซ้ำแล้วซ้ำอีก): เมื่อขนาดที่ช่วงกลางทางรับได้เล็กลง แต่ข้อความแจ้งว่า “ใหญ่เกินไป” (ICMP) ถูกบล็อก แพ็กเก็ตใหญ่จะหายไปทุกครั้งไม่ว่าจะส่งซ้ำกี่รอบ (อินฟราเครือข่าย (ทีมอินฟรา))
• การส่งซ้ำคำขอเชื่อมต่อ (SYN): ถ้าคำขอเชื่อมต่อหายไปเพราะคิวรอเชื่อมต่อ (backlog) ล้นหรือถูกไฟร์วอลล์บล็อก OS ฝั่งไคลเอนต์จะส่งใหม่ โดยเริ่มหลัง 1 วินาทีและเว้นช่วงห่างขึ้นเรื่อย ๆ (พัฒนาเซิร์ฟเวอร์ (ทีมพัฒนาเกม))

ดูพจนานุกรมอาการในฉบับหลักที่มีภาพ