413 Request Entity Too Large — ทำไมแก้แล้วยังไม่หาย

อัปเดต 2026-09-09อ่าน ~9 นาที

413 Request Entity Too Large แปลตรงตัวว่าสิ่งที่คุณส่งมาใหญ่เกินกว่าที่เซิร์ฟเวอร์ยอมรับ เจอบ่อยที่สุดตอนอัปโหลดรูป วิดีโอ ไฟล์สำรองข้อมูล หรือ import ฐานข้อมูลก้อนใหญ่

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

บทความนี้ไล่ให้ครบทุกชั้น เรียงตามลำดับที่ควรแก้ พร้อมกับดักสองสามข้อที่ทำให้แก้ถูกแล้วแต่ยังไม่หาย

ลิมิตมีกี่ชั้น

นี่คือหัวใจของบทความ ถ้าเข้าใจตารางนี้ก็แก้ได้เองแทบทุกเคส

ชั้น	ค่าที่คุม	ค่าเริ่มต้นที่พบบ่อย
Nginx	client_max_body_size	1 MB
Apache	LimitRequestBody	ไม่จำกัด (แต่บางโฮสต์ตั้งไว้)
PHP	upload_max_filesize	2 MB
PHP	post_max_size	8 MB
Cloudflare (ผ่าน proxy)	ลิมิตของแพ็กเกจ	100 MB (แพ็กเกจฟรี)
แอปพลิเคชัน	ลิมิตของตัวแอปเอง	แล้วแต่ระบบ

💡 request ต้องผ่านทุกชั้นที่มีในเส้นทางของมัน ชั้นที่ตั้งไว้ต่ำสุดคือชั้นที่ตัดสิน ดังนั้นการขยับ PHP เป็น 100MB แต่ลืม Nginx ที่ยัง 1MB อยู่ จะไม่เปลี่ยนอะไรเลย

แก้ที่ Nginx

ถ้าเป็น Nginx นี่คือชั้นที่เจอบ่อยที่สุด เพราะค่าเริ่มต้นแค่ 1 MB ซึ่งต่ำกว่ารูปจากมือถือสมัยนี้ด้วยซ้ำ

เพิ่มบรรทัด client_max_body_size ในไฟล์ตั้งค่า ใส่ได้ทั้งในบล็อก http (มีผลทั้งเซิร์ฟเวอร์) บล็อก server (เฉพาะเว็บนั้น) หรือบล็อก location (เฉพาะบางเส้นทาง) เช่นตั้งเป็น 64m หรือ 128m ตามที่ต้องการจริง

จากนั้นทดสอบไฟล์ตั้งค่าด้วย nginx -t ก่อนเสมอ แล้วค่อย reload — ถ้ารีสตาร์ตทั้งที่ไฟล์ผิดไวยากรณ์ บริการจะไม่ขึ้นและเว็บจะล่มทันที

ข้อควรระวัง: ถ้าตั้งไว้หลายที่ ค่าที่อยู่ในบล็อกเจาะจงกว่าจะชนะ ดังนั้นถ้าแก้ที่ http แล้วยังไม่หาย ให้ไปดูว่ามีค่าเก่าค้างอยู่ในบล็อก server หรือ location ไหม

💡 ตั้งเท่าที่จำเป็นจริง อย่าตั้งเป็น 0 (ไม่จำกัด) บนเว็บสาธารณะ เพราะเปิดช่องให้มีคนยิงไฟล์ขนาดมหาศาลใส่จนเต็มดิสก์หรือกินแรมหมด

แก้ที่ PHP — และกับดักที่คนพลาดบ่อยที่สุด

ฝั่ง PHP มีสองค่าที่ต้องแก้คู่กัน และนี่คือจุดที่คนแก้ไม่ครบบ่อยที่สุด

upload_max_filesize คือขนาดสูงสุดของไฟล์แต่ละไฟล์ ส่วน post_max_size คือขนาดสูงสุดของทั้ง request รวมกัน กฎคือ post_max_size ต้องมากกว่า upload_max_filesize เสมอ เพราะ request หนึ่งยังมีข้อมูลฟอร์มอื่นปนมาด้วย

และถ้าระบบของคุณอัปโหลดหลายไฟล์พร้อมกัน post_max_size ต้องรองรับผลรวมของทุกไฟล์ ไม่ใช่แค่ไฟล์ที่ใหญ่ที่สุด — คนที่ตั้ง upload 50MB / post 50MB แล้วอัปสามไฟล์ ๆ ละ 20MB จะยังเจอ error อยู่

ตั้งที่ไหน: แก้ใน php.ini ถ้ามีสิทธิ์ หรือใน .user.ini / .htaccess ตามที่โฮสต์อนุญาต ถ้าใช้ PHP-FPM ต้องรีสตาร์ต php-fpm ด้วย ไม่ใช่แค่ reload เว็บเซิร์ฟเวอร์ — ข้อนี้ทำให้หลายคนคิดว่าค่าไม่ยอมเปลี่ยน

ตรวจว่าค่ามีผลจริงด้วย phpinfo() หรือคำสั่ง php -i แล้วดูค่าที่อ่านได้จริง อย่าเชื่อว่าแก้ไฟล์แล้วต้องมีผล เพราะบางระบบมี php.ini หลายไฟล์และไฟล์ที่ถูกใช้จริงอาจไม่ใช่ไฟล์ที่คุณเพิ่งแก้

กับดัก Cloudflare ที่คนโทษเซิร์ฟเวอร์ตัวเอง

ถ้าเว็บวิ่งผ่าน Cloudflare แบบ proxy (เมฆสีส้ม) จะมีลิมิตอีกชั้นที่ไม่ได้อยู่บนเซิร์ฟเวอร์ของคุณเลย

แพ็กเกจฟรีจำกัดขนาด request ที่ประมาณ 100 MB และแพ็กเกจเสียเงินก็มีเพดานของมันเอง ถ้าไฟล์ใหญ่กว่านั้น Cloudflare จะปฏิเสธตั้งแต่ก่อนถึงเซิร์ฟเวอร์ ซึ่งแปลว่าคุณจะแก้ค่าบนเซิร์ฟเวอร์เท่าไรก็ไม่มีทางหาย

วิธียืนยันง่ายมาก: ลองอัปโหลดโดยต่อตรงเข้าเซิร์ฟเวอร์ ข้าม Cloudflare (แก้ไฟล์ hosts ชี้โดเมนไปที่ IP จริงชั่วคราว) ถ้าอัปได้แปลว่าตัวจำกัดคือ Cloudflare

ทางแก้ที่ใช้ได้จริงคือไม่ส่งไฟล์ใหญ่ผ่าน proxy — ใช้ subdomain แยกที่ปิด proxy สำหรับการอัปโหลด หรือให้อัปโหลดตรงไปยัง object storage แทนที่จะผ่านเว็บเซิร์ฟเวอร์ ซึ่งเป็นแนวทางที่ดีกว่าสำหรับไฟล์ใหญ่อยู่แล้ว

💡 อาการที่บ่งชี้: ไฟล์เล็กอัปได้ ไฟล์ใหญ่ไม่ได้ และ error page หน้าตาเป็นของ Cloudflare ไม่ใช่ของเว็บเซิร์ฟเวอร์เรา

แก้ครบแล้วแต่ยังไม่หาย — เช็กสามข้อนี้

ลืมรีสตาร์ตบริการที่ถูกต้อง แก้ php.ini ต้องรีสตาร์ต php-fpm ไม่ใช่แค่ reload nginx ส่วนแก้ nginx.conf ต้อง reload nginx
มีค่าเก่าค้างในบล็อกที่เจาะจงกว่า ตั้ง client_max_body_size ไว้ที่ http แต่ในบล็อก location ของเส้นทางที่อัปโหลดยังมีค่าเดิมอยู่
ค่าที่มีผลจริงไม่ใช่ไฟล์ที่คุณแก้ ระบบมี php.ini หลายไฟล์ หรือโฮสต์ override ค่าไว้ ให้เช็กด้วย phpinfo() ว่าไฟล์ไหนถูกโหลดจริงและค่าปัจจุบันเป็นเท่าไร
ติดลิมิตของแอปพลิเคชันเอง WordPress, DirectAdmin หรือแอปที่ใช้ อาจมีค่าจำกัดของตัวเองแยกจากเซิร์ฟเวอร์
ไฟล์ใหญ่จนหมดเวลาก่อน ถ้าขนาดผ่านแล้วแต่การอัปโหลดใช้เวลานานเกิน max_execution_time หรือ max_input_time จะได้ error คนละตัว (มักเป็น 504 หรือหน้าเปล่า) ซึ่งทำให้สับสนว่าแก้ไม่สำเร็จ

ถ้าใช้ shared hosting แล้วแก้ไม่ได้

ตรงนี้พูดตามตรง เพราะเป็นข้อจำกัดที่แก้ด้วยการตั้งค่าไม่ได้

บน shared hosting คุณมักแก้ได้แค่ฝั่ง PHP ผ่าน .user.ini หรือ .htaccess ส่วนค่า client_max_body_size ของ Nginx เป็นของระดับเซิร์ฟเวอร์ที่ทุกคนใช้ร่วมกัน ผู้ให้บริการจึงไม่เปิดให้ลูกค้าแก้ ถ้าเพดานของโฮสต์คือ 8MB ก็คือ 8MB

ทางเลือกมีสามทาง หนึ่งคือขอให้ผู้ให้บริการปรับให้ ซึ่งบางเจ้าทำให้ได้ สองคือเปลี่ยนวิธีอัปโหลดไปใช้ object storage หรืออัปผ่าน FTP/SFTP แทนแล้วค่อยให้ระบบไปหยิบไฟล์ สามคือย้ายไป VPS ที่คุมไฟล์ตั้งค่าเองได้ทั้งหมด

ทางที่สองมักเป็นทางที่ดีที่สุดถ้าเป็นเรื่องไฟล์ใหญ่จริง ๆ เพราะการส่งไฟล์หลายร้อยเมกะไบต์ผ่าน HTTP request เดียวเป็นวิธีที่เปราะบางอยู่แล้ว ไม่ว่าจะตั้งลิมิตไว้เท่าไร

อยากแก้ไฟล์ตั้งค่าเองได้ทุกชั้น?

Cloud VPS NVMe สิทธิ์ root เต็ม — แก้ nginx.conf และ php.ini ได้เอง ไม่ติดเพดานของโฮสต์ เริ่ม ฿150/เดือน

ดูแพ็กเกจ VPS สั่งซื้อทันที

คำถามที่พบบ่อย

แก้ upload_max_filesize แล้วทำไมยังอัปไม่ได้

เกือบทุกครั้งเพราะยังไม่ได้แก้ post_max_size ด้วย หรือยังไม่ได้แก้ client_max_body_size ฝั่ง Nginx ลิมิตมีหลายชั้นและชั้นที่ต่ำสุดเป็นตัวตัดสิน ให้เช็กด้วย phpinfo() ว่าค่ามีผลจริง และอย่าลืมรีสตาร์ต php-fpm

ควรตั้งลิมิตไว้เท่าไร

ตั้งเท่าที่งานจริงต้องการบวกเผื่อนิดหน่อย เช่นถ้าอัปรูปจากมือถือ 32–64MB ก็พอ อย่าตั้งเป็นไม่จำกัดบนเว็บสาธารณะ เพราะเปิดช่องให้ยิงไฟล์ใหญ่ใส่จนดิสก์เต็มหรือแรมหมด

413 กับ 414 ต่างกันยังไง

413 คือ body ของ request ใหญ่เกิน ซึ่งเกิดตอนอัปโหลดไฟล์หรือส่งฟอร์มใหญ่ ส่วน 414 URI Too Long คือตัว URL เองยาวเกิน มักเกิดจาก query string ที่ยาวผิดปกติ คนละสาเหตุและแก้คนละที่

เว็บอยู่หลัง Cloudflare แก้บนเซิร์ฟเวอร์แล้วไม่หาย

Cloudflare มีลิมิตของตัวเอง (แพ็กเกจฟรีราว 100MB) ซึ่งอยู่ก่อนเซิร์ฟเวอร์คุณ ลองอัปโหลดโดยข้าม Cloudflare เพื่อยืนยัน ถ้าข้ามแล้วได้ ให้เลี่ยงส่งไฟล์ใหญ่ผ่าน proxy — แยก subdomain ที่ปิด proxy หรืออัปตรงไป object storage