คู่มือแก้ไขปัญหา n8n Self-Hosted ฉบับสมบูรณ์ 2025: การแก้ไขปัญหาขนาดข้อมูลการรันและ Webhook กับ Traefik
อัปเดตล่าสุด: 15 ตุลาคม 2025
การโฮสต์ n8n ด้วยตัวเองให้การรันเวิร์กโฟลว์ไม่จำกัด การควบคุมข้อมูลอย่างสมบูรณ์ และการประหยัดต้นทุนอย่างมีนัยสำคัญเมื่อเทียบกับแผนคลาวด์ แต่ในความเป็นจริง instance แบบ self-hosted เผชิญกับความท้าทายเฉพาะที่ผู้ใช้คลาวด์ไม่เคยพบ – โดยเฉพาะเกี่ยวกับการจัดการข้อมูลขนาดใหญ่และการกำหนดค่า webhook กับ reverse proxies
ในเดือนมิถุนายน 2025 เราเผยแพร่คู่มือแก้ไขปัญหาสองฉบับที่จัดการปัญหาเหล่านี้แยกกัน ปัญหาคือไม่มีคู่มือฉบับสมบูรณ์สำหรับการปรับใช้ n8n ระดับ production กับ Traefik reverse proxy ที่จัดการทั้งสองปัญหาทั่วไปพร้อมกัน
คู่มือนี้รวมการแก้ไขต้นฉบับทั้งสองฉบับ ให้การกำหนดค่า Traefik ฉบับสมบูรณ์พร้อมรองรับ WebSocket รวมข้อกำหนด task runner ใหม่ของปี 2025 และให้ไฟล์ docker-compose ระดับ production ที่พร้อมปรับใช้ได้ทันที
สารบัญ
- การวินิจฉัยอย่างรวดเร็ว: คุณมีปัญหาอะไร?
- ทำความเข้าใจสองปัญหาหลัก
- การแก้ไข #1: ข้อผิดพลาดข้อมูลการรันใหญ่เกินไป
- การแก้ไข #2: ปัญหา URL ของ Webhook
- การตั้งค่า Production ฉบับสมบูรณ์กับ Traefik
- ข้อกำหนดปี 2025: Task Runners
- เอกสารอ้างอิงตัวแปรสภาพแวดล้อม
- ตัวอย่าง Docker Compose
- การทดสอบการตั้งค่า
- การแก้ไขปัญหาที่พบบ่อย
การวินิจฉัยอย่างรวดเร็ว: คุณมีปัญหาอะไร?
อาการ: “Existing execution data is too large”
คุณเห็นข้อผิดพลาดนี้เมื่อ:
- คลิก “Execute Node” ระหว่างการพัฒนาเวิร์กโฟลว์
- ทดสอบเวิร์กโฟลว์ที่มีชุดข้อมูลขนาดใหญ่หรือรายการจำนวนมาก
- ใช้โหมดการรันบางส่วน (ทดสอบโหนดเดียว)
- ประมวลผลการแปลงที่ซับซ้อนที่มีหลาย branch
คุณต้องการ: การแก้ไข #1: ขนาดข้อมูลการรัน
อาการ: Webhook แสดง URL ไม่ถูกต้องหรือไม่ทำงาน
คุณเห็นสิ่งนี้เมื่อ:
- URL ของ webhook แสดงหมายเลขพอร์ต (เช่น
:5678) - บริการภายนอก (Slack, GitHub, Stripe) ไม่สามารถเข้าถึง webhook ได้
- Webhook ทำงานในโหมดทดสอบแต่ล้มเหลวใน production
- คุณใช้ reverse proxy (Nginx, Traefik, Caddy)
คุณต้องการ: การแก้ไข #2: การกำหนดค่า URL ของ Webhook
อาการ: คำเตือนการเลิกใช้เกี่ยวกับ task runners
คุณเห็น logs ที่บอกว่า:
Running n8n without task runners is deprecated. Task runners will be
turned on by default in a future version.
คุณต้องการ: การกำหนดค่า Task Runners
อาการ: คุณต้องการการตั้งค่าระดับ production ที่สมบูรณ์
คุณต้องการ:
- การแก้ไขทั้งสองถูกนำไปใช้อย่างถูกต้อง
- Traefik reverse proxy พร้อม HTTPS อัตโนมัติ
- แนวปฏิบัติที่ดีที่สุดสำหรับ production และความปลอดภัย
- ขีดจำกัดทรัพยากรและการตรวจสอบที่เหมาะสม
ข้ามไปที่: การตั้งค่า Production ฉบับสมบูรณ์
ทำความเข้าใจสองปัญหาหลัก
ทำไม n8n Cloud จึงไม่มีปัญหาเหล่านี้
n8n Cloud จัดการขีดจำกัดหน่วยความจำที่สูงขึ้นสำหรับการรันบางส่วน URL webhook ที่ถูกต้อง การจัดเก็บข้อมูลไบนารีที่เพิ่มประสิทธิภาพ และการอัปเดตอัตโนมัติรวมถึงข้อกำหนดใหม่ทั้งหมดโดยอัตโนมัติ เมื่อคุณโฮสต์ด้วยตัวเอง คุณรับผิดชอบการกำหนดค่าเหล่านี้
สาเหตุหลัก
ปัญหา #1: ขีดจำกัดขนาดข้อมูลการรัน
ขีดจำกัดค่าเริ่มต้น 16MB สำหรับข้อมูลการรันบางส่วนที่ส่งไปยัง backend ทำให้เกิดข้อผิดพลาดเมื่อทำงานกับชุดข้อมูลขนาดใหญ่ หลาย branch ของเวิร์กโฟลว์ หรือการแปลงที่ซับซ้อน ปัญหาคือการพัฒนาเวิร์กโฟลว์กลายเป็นเรื่องน่าหงุดหงิด – คุณไม่สามารถทดสอบโหนดเดียวระหว่างการพัฒนาได้ การแก้ไขตรงไปตรงมา: ตัวแปรสภาพแวดล้อม N8N_PAYLOAD_SIZE_MAX
ปัญหา #2: การสร้าง URL ของ Webhook
n8n พยายามตรวจจับ URL สาธารณะของคุณโดยอัตโนมัติ แต่การตรวจจับอัตโนมัตินี้ล้มเหลวเมื่ออยู่หลัง reverse proxy บริการภายนอกได้รับ URL webhook ที่ไม่ถูกต้องพร้อมพอร์ตหรือ hostnames ภายใน – การบูรณาการเสียหายอย่างเงียบๆ การแก้ไข: ตัวแปรสภาพแวดล้อม WEBHOOK_URL
การแก้ไข #1: ข้อผิดพลาดข้อมูลการรันใหญ่เกินไป
ปัญหาอย่างละเอียด
เมื่อคุณรันเฉพาะส่วนหนึ่งของเวิร์กโฟลว์ (คลิก “Execute Node” ใน editor) n8n จำเป็นต้องโหลดข้อมูลการรันก่อนหน้าเพื่อให้บริบทแก่โหนดนั้น โดยค่าเริ่มต้น n8n จำกัดการถ่ายโอนข้อมูลนี้ไว้ที่ 16MB เพื่อป้องกันปัญหาหน่วยความจำบนเซิร์ฟเวอร์ขนาดเล็ก
ข้อความผิดพลาด
ตามเอกสาร n8n อย่างเป็นทางการ:
Please execute the whole workflow, rather than just the node.
(Existing execution data is too large.)
ข้อผิดพลาดนี้ปรากฏเมื่อประมวลผลรายการหลายพันรายการในโหนดเดียว ทำงานกับการตอบกลับ JSON API ขนาดใหญ่ แปลงชุดข้อมูลขนาดใหญ่ด้วยโหนด Code หรือใช้เวิร์กโฟลว์ที่มีหลาย branch ขนาน
โซลูชัน: N8N_PAYLOAD_SIZE_MAX
การแก้ไขง่ายแต่ต้องเข้าใจทรัพยากรที่มีอยู่ของเซิร์ฟเวอร์
การตั้งค่าที่แนะนำตาม RAM ของเซิร์ฟเวอร์
| RAM เซิร์ฟเวอร์ | N8N_PAYLOAD_SIZE_MAX | ค่าเป็น Bytes | เปอร์เซ็นต์ของ RAM |
|---|---|---|---|
| 2GB หรือน้อยกว่า | 64MB | 67108864 | ~3% |
| 4GB | 128MB | 134217728 | ~3% |
| 8GB | 256MB | 268435456 | ~3% |
| 16GB+ | 512MB | 536870912 | ~3% |
กฎทั่วไป: ใช้น้อยกว่า 20% ของ RAM ที่มีอยู่เพื่อรักษาความเสถียรของระบบภายใต้ภาระงาน
สำหรับการนำไปใช้ Docker Compose อย่างละเอียด การกำหนดค่า Traefik ฉบับสมบูรณ์พร้อมรองรับ WebSocket ข้อกำหนด Task Runner ตัวอย่าง Docker Compose ที่พร้อมใช้งาน ขั้นตอนการทดสอบ และการแก้ไขปัญหาที่พบบ่อยทั้งหมด กรุณาดูเนื้อหาฉบับเต็มในเวอร์ชันภาษาอังกฤษ code blocks และคำสั่งทางเทคนิคทั้งหมดเหมือนกันทุกประการ
การแก้ไข #2: ปัญหา URL ของ Webhook
เมื่อ n8n ทำงานหลัง reverse proxy จำเป็นต้องตั้งค่าตัวแปรสภาพแวดล้อม WEBHOOK_URL เพื่อให้ n8n สร้าง URL webhook ที่ถูกต้อง สิ่งนี้เป็นอัตโนมัติในโซลูชันคลาวด์แต่ต้องกำหนดค่าด้วยตนเองในการตั้งค่าแบบ self-hosted
environment:
- WEBHOOK_URL=https://n8n.yourdomain.com
ข้อกำหนดปี 2025: Task Runners
ตั้งแต่ n8n เวอร์ชัน 1.x+ ในปี 2025 task runners ถูกกำหนดให้เปิดใช้งาน เพิ่มตัวแปรสภาพแวดล้อมนี้เพื่อขจัดคำเตือนการเลิกใช้:
environment:
- N8N_RUNNERS_ENABLED=true
การทดสอบที่ทำซ้ำได้
การกำหนดค่าทั้งหมดในคู่มือนี้สามารถทำซ้ำได้ในสภาพแวดล้อมของคุณเอง – ไฟล์ Docker Compose พร้อมสำหรับ production ตัวแปรสภาพแวดล้อมได้รับการบันทึกและตรวจสอบแล้ว คำสั่งทดสอบให้ไว้สำหรับการตรวจสอบ และผลลัพธ์ที่คาดหวังระบุไว้อย่างชัดเจน คุณสามารถตรวจสอบทุกข้ออ้างในคู่มือนี้โดยปรับใช้การกำหนดค่าด้วยตัวเองและรันการทดสอบที่ให้ไว้
ต้องการความช่วยเหลือในการนำไปใช้?
หากคุณต้องการให้ tva จัดการการปรับใช้ n8n ของคุณหรือต้องการความช่วยเหลือในการตั้งค่า production ติดต่อเรา เรานำการกำหนดค่าเหล่านี้ไปใช้สำหรับองค์กรที่ต้องการโครงสร้างพื้นฐาน n8n ที่น่าเชื่อถือและพร้อมสำหรับ production
เผยแพร่: 15 ตุลาคม 2025
ทดสอบกับ: n8n v1.115.2, Docker Compose v3.8, Traefik v2.10
ข้อกำหนดเซิร์ฟเวอร์: แนะนำ RAM 4GB+ และ CPU 2+ cores สำหรับ production
อิงจาก: เอกสาร n8n อย่างเป็นทางการ การทดสอบ Docker ที่ตรวจสอบแล้ว และแนวปฏิบัติที่ดีที่สุดของชุมชน