nginx Reverse Proxy: คู่มือตั้งค่าแบบครบถ้วน

nginx reverse proxy คือเซิร์ฟเวอร์ nginx ที่รับคำขอขาเข้าแทนแอปพลิเคชันแบ็กเอนด์หนึ่งรายการหรือมากกว่า จากนั้นส่งต่อคำขอแต่ละรายการไปยังแบ็กเอนด์ที่ถูกต้องและส่งคำตอบกลับให้ไคลเอนต์ คู่มือนี้มอบการกำหนดค่า nginx reverse proxy แบบครบถ้วนที่พร้อมคัดลอกใช้ได้ทันที: server block ฉบับเต็มพร้อม proxy_pass และ forwarded headers, การทำ load balancing ด้วย upstream, การสิ้นสุด SSL, การรองรับ WebSocket, การปรับ buffering และ timeout, gzip, การกำหนดเส้นทางตาม location และวิธีแก้ข้อผิดพลาด 502 กับ 504 ที่มักทำให้หลายคนติดขัด

เมื่อจบแล้วจะมีการตั้งค่า nginx reverse proxy ที่นำไปใช้งานได้จริง ความเข้าใจภาพรวมว่าชิ้นส่วนต่าง ๆ ทำงานร่วมกันอย่างไร และมุมมองตรงไปตรงมาว่าจุดใด nginx reverse proxy ไม่ใช่เครื่องมือที่เหมาะสมอีกต่อไปและควรใช้ forward หรือ residential proxy แทน

DataImpulse คือผู้ให้บริการ proxy ที่มีจริยธรรม ซึ่งมี IP แบบ residential, mobile และ datacenter มากกว่า 90 ล้านรายการใน 195 ประเทศ ใช้โมเดลจ่ายตามการใช้งาน เริ่มต้นที่ 1 ดอลลาร์ต่อ GB พร้อมทราฟฟิกที่ไม่หมดอายุ และใช้สำหรับ web scraping, ad verification, การติดตามราคา, การวิจัยตลาด และการจัดการหลายบัญชี

ข้อมูลสำคัญ

• nginx reverse proxy: การตั้งค่าที่ถูกต้องต้องมี 4 ส่วนร่วมกัน ได้แก่ เป้าหมาย proxy_pass, headers Host และ X-Forwarded, upstream block สำหรับ load balancing และ TLS บน listen 443 ไม่ใช่เพียง proxy_pass อย่างเดียว
• ประเภท proxy ที่เหมาะที่สุด: rotating residential proxies ซึ่งใช้ IP ของผู้ใช้งานจริงที่ผ่านการตรวจจับได้
• ราคา: เริ่มต้นที่ 1 ดอลลาร์ต่อ GB จ่ายตามการใช้งาน ทราฟฟิกไม่หมดอายุ และไม่มีการสมัครสมาชิก
• ความครอบคลุม: IP ที่จัดหามาอย่างมีจริยธรรมมากกว่า 90M ใน 195 ประเทศ
• ความน่าเชื่อถือ: อัตราความสำเร็จ 99.51% คะแนน 4.8 จาก 5 บน G2
• โปรโตคอลและการระบุตำแหน่ง: HTTP, HTTPS และ SOCKS5 พร้อมการเลือกประเทศ

nginx เป็น reverse proxy หรือไม่ และทำงานอย่างไร?

ใช่ nginx เป็นหนึ่งใน reverse proxy ที่ถูกนำไปใช้งานอย่างแพร่หลายที่สุด และความสามารถด้าน reverse proxy เป็นฟีเจอร์หลัก ไม่ใช่ส่วนเสริม reverse proxy อยู่หน้าฝั่งเซิร์ฟเวอร์แบ็กเอนด์ รับการเชื่อมต่อของไคลเอนต์บน hostname สาธารณะ และกำหนดเส้นทางคำขอแต่ละรายการไปยังแอปพลิเคชันภายในที่ไคลเอนต์ไม่เห็นโดยตรง

เพื่อให้เห็นส่วนที่เคลื่อนไหวต่าง ๆ อย่างชัดเจน คู่มือนี้ใช้โมเดลแบบตั้งชื่อเรียบง่าย เรียกว่า โมเดล nginx reverse-proxy 5 ชั้น และการกำหนดค่าที่ใช้งานได้ทั้งหมดด้านล่างก็เป็นเพียงชั้นเหล่านี้ที่วางซ้อนกันตามลำดับ:

• ตัวรับฟัง. คำสั่ง listen และ server_name เป็นตัวกำหนดว่าคำขอใดอยู่ในความรับผิดชอบของ block นี้ (พอร์ต 80, พอร์ต 443, hostname ใด)
• การกำหนดเส้นทาง location. block location แยกเส้นทางขาเข้า เพื่อให้ /api/, /static/ และ / ไปยังปลายทางต่างกันได้
• Upstream. block upstream ตั้งชื่อกลุ่มเซิร์ฟเวอร์แบ็กเอนด์และวิธีทำ load balancing
• Headers. บรรทัด proxy_set_header คง Host เดิมและ IP ของไคลเอนต์ไว้ เพื่อให้แบ็กเอนด์เห็นคำขอจริง ไม่ใช่ nginx
• TLS. ssl_certificate บน listen 443 ทำการสิ้นสุด HTTPS ที่ nginx เพื่อให้แบ็กเอนด์สื่อสารด้วย HTTP ปกติภายในได้

หากยังตัดสินใจระหว่างทิศทาง proxy ทั้งสองแบบอยู่ บทอธิบายของเราเรื่อง reverse proxy เทียบกับ forward proxy ครอบคลุมแนวคิดอย่างครบถ้วน บทความนี้กล่าวถึงเฉพาะกรณี reverse สำหรับการตั้งค่าฝั่งไคลเอนต์และขาออก โปรดดูคู่มือ nginx forward proxy ที่เกี่ยวข้อง

ต้องมีอะไรบ้างก่อนเริ่มต้น?

ต้องมีเซิร์ฟเวอร์ Linux ที่ติดตั้ง nginx แล้ว แอปพลิเคชันแบ็กเอนด์อย่างน้อยหนึ่งรายการที่รับฟังพอร์ตภายใน และ TLS certificate สำหรับ HTTPS การทำ reverse proxy ใช้เพียง nginx รุ่นมาตรฐาน จึงไม่ต้องมีโมดูลพิเศษหรือคอมไพล์ใหม่

ยืนยันว่ามี nginx และการกำหนดค่าถูกต้องก่อนแก้ไขสิ่งใด:

nginx -v
sudo nginx -t

การทดสอบ nginx -t จะแยกวิเคราะห์การกำหนดค่าทั้งหมด และรายงานข้อผิดพลาดไวยากรณ์พร้อมชื่อไฟล์และหมายเลขบรรทัด ให้รันหลังเปลี่ยนแปลงทุกครั้งในคู่มือนี้ เพราะ nginx จะไม่ยอม reload การกำหนดค่าที่เสียและจะปล่อยให้ของเดิมทำงานต่อไป วาง reverse-proxy server block ไว้ที่ /etc/nginx/conf.d/ หรือ /etc/nginx/sites-available/ ตาม distribution และ reload ด้วย sudo nginx -s reload เมื่อการทดสอบผ่าน เตรียม address ของแบ็กเอนด์ไว้ด้วย เช่นแอป Node หรือ Python บน 127.0.0.1:3000 เพราะนั่นคือจุดที่ proxy_pass จะชี้ไป

ตั้งค่า nginx reverse proxy ทีละขั้นตอนอย่างไร?

เริ่มจาก server block เดียวที่รับฟังพอร์ต 80 ส่งต่อทุกคำขอไปยังแบ็กเอนด์หนึ่งรายการด้วย proxy_pass และตั้งค่า forwarded headers จากนั้นจึงเพิ่ม load balancing, TLS, WebSocket, buffering และ gzip block แรกนี้คือการตั้งค่า nginx reverse proxy ขั้นต่ำที่ใช้งานได้:

server {
    listen 80;
    server_name app.example.com;

    location / {
        proxy_pass http://127.0.0.1:3000;
        proxy_set_header Host              $host;
        proxy_set_header X-Real-IP         $remote_addr;
        proxy_set_header X-Forwarded-For   $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

บรรทัด proxy_set_header ทั้ง 4 บรรทัดนี้ไม่ใช่ตัวเลือก หากไม่มี บริการแบ็กเอนด์จะเห็น nginx เป็นไคลเอนต์ บันทึก IP ผิด และอาจสร้าง URL เปลี่ยนเส้นทางที่เสีย Host คง hostname ที่ร้องขอไว้ X-Real-IP และ X-Forwarded-For ส่ง address จริงของไคลเอนต์ และ X-Forwarded-Proto บอกแอปว่าคำขอเดิมเป็น HTTP หรือ HTTPS

เพิ่ม upstream load balancing หากต้องอยู่หน้าฝั่งแบ็กเอนด์หลาย instance ให้กำหนด block upstream และชี้ proxy_pass ไปยังชื่อนั้น วิธี least_conn จะส่งแต่ละคำขอไปยัง instance ที่มีการเชื่อมต่อที่ใช้งานอยู่น้อยที่สุด:

upstream app_backend {
    least_conn;
    server 10.0.0.11:3000;
    server 10.0.0.12:3000;
    server 10.0.0.13:3000 backup;
}

server {
    listen 80;
    server_name app.example.com;

    location / {
        proxy_pass http://app_backend;
        proxy_set_header Host              $host;
        proxy_set_header X-Forwarded-For   $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

เซิร์ฟเวอร์ backup จะได้รับทราฟฟิกเฉพาะเมื่อเซิร์ฟเวอร์หลักล่ม เปลี่ยนเป็น ip_hash แทน least_conn หากต้องการให้ไคลเอนต์เดิมยึดกับแบ็กเอนด์เดิมสำหรับ sticky session

สิ้นสุด SSL บนพอร์ต 443 reverse proxy สำหรับ production ควรให้บริการ HTTPS และเปลี่ยนเส้นทาง HTTP ปกติ nginx จัดการ TLS เพื่อให้แบ็กเอนด์ยังใช้ HTTP ปกติภายในได้:

server {
    listen 443 ssl;
    server_name app.example.com;

    ssl_certificate     /etc/letsencrypt/live/app.example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/app.example.com/privkey.pem;
    ssl_protocols       TLSv1.2 TLSv1.3;

    location / {
        proxy_pass http://app_backend;
        proxy_set_header Host              $host;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

server {
    listen 80;
    server_name app.example.com;
    return 301 https://$host$request_uri;
}

รองรับ WebSocket การเชื่อมต่อ WebSocket เริ่มต้นเป็น HTTP แล้วจึง upgrade ดังนั้น nginx ต้องส่งผ่าน headers Upgrade และ Connection และใช้ HTTP/1.1 กำหนด location แยกให้เส้นทางแบบเรียลไทม์:

location /ws/ {
    proxy_pass http://app_backend;
    proxy_http_version 1.1;
    proxy_set_header Upgrade    $http_upgrade;
    proxy_set_header Connection "upgrade";
    proxy_set_header Host       $host;
    proxy_read_timeout 3600s;
}

proxy_read_timeout ที่ยาวช่วยไม่ให้ socket ที่ว่างอยู่ถูกปิดกลาง session ซึ่งเป็นสาเหตุทั่วไปที่ทำให้การเชื่อมต่อแบบ live หลุด

ปรับ buffering และ timeout ค่าเริ่มต้นค่อนข้างระมัดระวัง แบ็กเอนด์ที่ช้าจะได้ประโยชน์จากค่าที่ระบุชัดเจน เพื่อให้ nginx ไม่ปิดการเชื่อมต่อก่อนแอปตอบกลับ:

location / {
    proxy_pass http://app_backend;
    proxy_connect_timeout 5s;
    proxy_send_timeout    60s;
    proxy_read_timeout    60s;
    proxy_buffering       on;
    proxy_buffers         16 16k;
    proxy_buffer_size     32k;
}

เปิดใช้ gzip การบีบอัดคำตอบที่ส่งผ่าน proxy ช่วยลด bandwidth สำหรับไฟล์ข้อความ วางส่วนนี้ใน block http เพื่อให้มีผลทั้งเว็บไซต์:

gzip on;
gzip_types text/plain text/css application/json application/javascript;
gzip_min_length 1024;
gzip_comp_level 5;

กำหนดเส้นทางตาม path reverse proxy เดียวสามารถอยู่หน้าบริการหลายรายการได้ โดยจับคู่ location prefix ต่างกันกับ upstream ต่างกัน และให้บริการไฟล์ static จาก disk โดยตรงโดยไม่ต้องผ่านแบ็กเอนด์:

server {
    listen 80;
    server_name example.com;

    location /api/ {
        proxy_pass http://api_backend;
        proxy_set_header Host $host;
    }

    location /static/ {
        root /var/www/assets;
    }

    location / {
        proxy_pass http://web_backend;
        proxy_set_header Host $host;
    }
}

ตรวจสอบว่า nginx reverse proxy ทำงานอย่างไร?

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

sudo nginx -t && sudo nginx -s reload
curl -I http://app.example.com

สถานะ 200 หรือ redirect ที่คาดไว้ใน response headers หมายความว่าการกำหนดเส้นทางทำงาน เพื่อตรวจสอบว่าแบ็กเอนด์ได้รับ forwarded headers ให้ดู access log หรือ echo endpoint และยืนยันว่าเห็น IP จริงของไคลเอนต์จาก X-Forwarded-For ไม่ใช่ 127.0.0.1 นอกจากนี้ยังสามารถข้าม DNS และชี้ไปยัง proxy โดยตรงพร้อมปลอม hostname:

curl -H "Host: app.example.com" http://127.0.0.1

สำหรับ HTTPS ให้รัน curl -I https://app.example.com และยืนยันว่า certificate ได้รับการยอมรับและคำขอไม่ได้ถูกลดระดับ หากแบ็กเอนด์แสดงลิงก์หรือ redirect ด้วย scheme ที่ผิด เกือบทุกครั้งเกิดจากไม่มี header X-Forwarded-Proto มากกว่าจะเป็นปัญหา TLS

แก้ไขข้อผิดพลาด 502 และ 504 อย่างไร?

502 Bad Gateway หมายถึง nginx ติดต่อ upstream ได้ แต่ได้รับคำตอบที่ไม่ถูกต้องหรือถูกปฏิเสธ ส่วน 504 Gateway Timeout หมายถึง upstream ยอมรับการเชื่อมต่อแต่ไม่ตอบทันเวลา ทั้งสองเป็นปัญหาของ upstream ไม่ใช่บั๊ก nginx และ error log จะระบุสาเหตุที่แน่นอน ดูแบบสดขณะสร้างคำขอเดิมซ้ำ:

sudo tail -f /var/log/nginx/error.log
# [error] connect() failed (111: Connection refused) while connecting to upstream

ตรวจสอบสาเหตุตามปกติตามลำดับ:

• 502, การเชื่อมต่อถูกปฏิเสธ แบ็กเอนด์ไม่ได้ทำงาน หรือรับฟัง address หรือพอร์ตที่ต่างจากเป้าหมายของ proxy_pass ยืนยันด้วย curl http://127.0.0.1:3000 บนเซิร์ฟเวอร์นั้นโดยตรง
• 502, SELinux หรือ firewall บนระบบตระกูล RHEL, SELinux จะบล็อก nginx ไม่ให้เปิดการเชื่อมต่อขาออก จนกว่าจะรัน setsebool -P httpd_can_network_connect 1
• 504, แบ็กเอนด์ช้า แอปใช้เวลาตอบนานกว่า proxy_read_timeout เพิ่ม timeout สำหรับ location นั้น หรือแก้ query ที่ช้า แทนที่จะปกปิดปัญหานี้ทั้งระบบ
• 502, headers ขนาดใหญ่ แบ็กเอนด์ที่ส่ง response headers ขนาดใหญ่อาจทำให้ proxy buffers ล้น เพิ่ม proxy_buffer_size และ proxy_buffers
• เลือก upstream ผิด หากเซิร์ฟเวอร์หนึ่งใน upstream pool ล่ม nginx จะทำเครื่องหมายว่าไม่พร้อมใช้งานและลองเซิร์ฟเวอร์ถัดไป ดังนั้น 502 ที่เกิดเป็นครั้งคราวมักชี้ไปที่แบ็กเอนด์ที่ไม่พร้อมใช้งานเพียงรายการเดียว

reverse proxy แบบใดเหมาะสม และเมื่อใดต้องใช้ proxy อื่น?

ใช้ nginx reverse proxy เมื่อทำการสิ้นสุด TLS, load balancing หรือกำหนดเส้นทางในหน้าฝั่งเซิร์ฟเวอร์ของตนเอง ใช้ forward หรือ residential proxy เมื่องานคือการส่งคำขอขาออกจาก IP จำนวนมาก nginx ยอดเยี่ยมสำหรับงานขาเข้าและไม่ได้ออกแบบมาสำหรับงานขาออก นี่คือตารางตัดสินใจ:

• ใช้ nginx reverse proxy เมื่อ เป็นผู้โฮสต์แบ็กเอนด์ ต้องการ endpoint HTTPS สาธารณะหนึ่งรายการเหนือบริการภายในหลายรายการ ต้องการ load balancing ระหว่าง instance หรืออยากใช้ caching และ gzip ที่ edge
• หลีกเลี่ยง nginx ในฐานะ proxy เมื่อ เป้าหมายคือคำขอขาออกที่ต้องดูเหมือนมาจาก IP หรือประเทศต่าง ๆ จำนวนมาก เพราะ reverse proxy ออกสู่ภายนอกจาก IP ของเซิร์ฟเวอร์เพียงรายการเดียวและไม่สามารถหมุนเวียน address ได้

เฉพาะในกลุ่ม reverse proxy นั้น nginx, Caddy และ HAProxy มีข้อแลกเปลี่ยนต่างกัน:

สำหรับระบบอัตโนมัติขาออกปริมาณมาก คู่มือ แนวปฏิบัติที่ดีสำหรับ web scraping ของเราครอบคลุมการหมุนเวียนและการควบคุมอัตรา และ datacenter proxies หรือ mobile proxies เหมาะกับงานที่ต้นทุนหรือ IP ของผู้ให้บริการเครือข่ายสำคัญกว่าความน่าเชื่อถือว่าเป็น residential จริง

ข้อจำกัดและความเสี่ยงของ nginx reverse proxy คืออะไร?

nginx reverse proxy มีประสิทธิภาพสำหรับทราฟฟิกขาเข้า แต่มีขีดจำกัดจริง: ไม่สามารถหมุนเวียน IP ขาออกได้ headers ที่กำหนดค่าผิดอาจเปิดเผยหรือซ่อนข้อมูลไคลเอนต์ และเพิ่มส่วนปฏิบัติการที่ต้อง patch และเฝ้าติดตาม การทราบเรื่องเหล่านี้ช่วยให้ความคาดหวังสมจริง

• IP ขาออกเดียว คำขอขาออกทุกคำขอจาก proxy ออกจาก IP ของเซิร์ฟเวอร์เอง ดังนั้น reverse proxy จึงไม่ช่วยงานที่ต้องใช้ source address จำนวนมาก
• ความผิดพลาดของ header ไม่ส่งสัญญาณ การลืม X-Forwarded-For ซ่อน IP จริงของไคลเอนต์จากแอปและการจำกัดอัตราของแอป การลืม X-Forwarded-Proto ทำให้ HTTPS redirect เสีย nginx จะไม่เตือน
• การดูแล TLS และ certificate certificate หมดอายุได้ จึงต้องรับผิดชอบการต่ออายุและ reload เอง โดยปกติผ่าน certbot และ cron job หรือ systemd timer
• จุดล้มเหลวใหม่ proxy อยู่ในเส้นทางสำคัญแล้ว หากล่ม แบ็กเอนด์ทุกตัวที่อยู่หลังมันจะเข้าถึงไม่ได้ นี่คือเหตุผลที่ health checks และ monitoring สำคัญ
• ไม่ใช่เครื่องมือปกปิดตัวตนขาออก reverse proxy ไม่ได้สร้างมาเพื่อปกปิดแหล่งที่มาของคำขอ นั่นเป็นหน้าที่ของ forward proxy

nginx ไม่ใช่ผลิตภัณฑ์ของ DataImpulse และ DataImpulse ไม่ได้จำหน่าย scraping API แบบจัดการให้หรือ web proxy ฟรี ใช้งาน nginx ด้วยตนเองในจุดที่เหมาะสม ส่วนเมื่อจำเป็นต้องขยายงานขาออก DataImpulse จัดหา IP ในรูปแบบ ethical proxies จากผู้ใช้ที่เลือกเข้าร่วมและได้รับค่าตอบแทน อัปเดตล่าสุด: 2026-07-22

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

คู่มือที่เกี่ยวข้อง

• NGINX Forward Proxy
• Cloudflare Reverse Proxy
• Docker Reverse Proxy

ต้องการ IP ขาออกที่ nginx หมุนเวียนไม่ได้หรือไม่?

reverse proxy จัดการทราฟฟิกขาเข้า แต่เมื่องานต้องการคำขอขาออกจาก IP จริงจำนวนมาก DataImpulse เพิ่ม IP แบบ rotating residential, mobile และ datacenter จำนวน 90M+ ใน 195 ประเทศ จ่ายตามการใช้งานเริ่มต้นที่ 1 ดอลลาร์ต่อ GB พร้อมทราฟฟิกไม่หมดอายุ สร้างบัญชี เพื่อรับ gateway credentials และกำหนดเส้นทางไคลเอนต์เข้าสู่ pool