โมดูล ngx_http_upstream_module ใช้ทำอะไร?

โมดูล ngx_http_upstream_module ใช้สำหรับกำหนดกลุ่มของเซิร์ฟเวอร์แบ็กเอนด์ที่ NGINX สามารถส่งต่อคำขอไปได้ โดยทำงานร่วมกับคำสั่งต่างๆ เช่น proxy_pass, fastcgi_pass และ uwsgi_pass เพื่อเปิดใช้งานการกระจายโหลดของแอปพลิเคชัน การจัดกลุ่มเซิร์ฟเวอร์หลายๆ ตัวเข้าด้วยกันทำให้ NGINX สามารถกระจายปริมาณการใช้งานขาเข้าโดยใช้กลยุทธ์การกระจายโหลดที่สามารถกำหนดค่าได้

คำถามและคำตอบสัมภาษณ์ Nginx 50 อันดับแรก (2026)

การเตรียมตัวสำหรับการสัมภาษณ์งาน Nginx ต้องอาศัยวิสัยทัศน์ ความชัดเจน และความเข้าใจในวิธีการที่ผู้สัมภาษณ์ประเมินความรู้ด้านการปฏิบัติงานจริงในปัจจุบัน คำถามสัมภาษณ์งาน Nginx จะเผยให้เห็นถึงความรู้เชิงลึก การตัดสินใจ ความสามารถในการแก้ไขปัญหา และความพร้อมในการทำงานในสภาพแวดล้อมการผลิต

ตำแหน่งงานเหล่านี้เปิดเส้นทางสู่โครงสร้างพื้นฐานคลาวด์ วิศวกรรมประสิทธิภาพ และความปลอดภัย ซึ่งการกำหนดค่าเชิงปฏิบัติมีความสำคัญ นายจ้างให้ความสำคัญกับประสบการณ์ทางเทคนิค ความเชี่ยวชาญเฉพาะด้าน และการวิเคราะห์ที่ได้จากการทำงานภาคสนาม ช่วยให้ผู้จบใหม่ วิศวกรระดับกลาง และผู้เชี่ยวชาญอาวุโสสามารถนำทักษะพื้นฐานไปจนถึงขั้นสูงไปใช้ในทีมภายใต้การแนะนำของผู้จัดการและหัวหน้าทีม อ่านเพิ่มเติม ...

👉 ดาวน์โหลดไฟล์ PDF ฟรี: คำถามและคำตอบสำหรับการสัมภาษณ์งาน Nginx

คำถามและคำตอบสัมภาษณ์งาน Nginx ที่สำคัญที่สุด

1) อธิบายว่า NGINX คืออะไร และเหตุใดจึงมีการใช้งานอย่างแพร่หลายในโครงสร้างพื้นฐานของเว็บ

NGINX เป็นเว็บเซิร์ฟเวอร์โอเพนซอร์สประสิทธิภาพสูง ที่ทำหน้าที่เป็นทั้งรีเวิร์สพร็อกซี โหลดบาลานเซอร์ และแคช HTTP รองรับโปรโตคอล HTTP, HTTPS, SMTP, POP3 และ IMAP สถาปัตยกรรมใช้... event-driven, asynchronous model ซึ่งช่วยให้สามารถจัดการการเชื่อมต่อพร้อมกันได้หลายหมื่นรายการโดยใช้หน่วยความจำและ CPU ในระดับต่ำ ความสามารถในการปรับขนาดนี้ทำให้ NGINX เหมาะอย่างยิ่งสำหรับเว็บแอปพลิเคชันที่มีปริมาณการใช้งานสูง ไมโครเซอร์วิส และสถาปัตยกรรมแบบกระจาย ตัวอย่างเช่น บริษัทที่มีปริมาณงานด้านการรับส่งข้อมูลสูง (เช่น แพลตฟอร์มเนื้อหาหรือเกตเวย์ API) มักเลือกใช้ NGINX เพื่อจัดการการเชื่อมต่อพร้อมกันและการส่งมอบเนื้อหาแบบคงที่ได้อย่างมีประสิทธิภาพ

2) NGINX จัดการคำขอ HTTP ภายในอย่างไร (สถาปัตยกรรมแบบขับเคลื่อนด้วยเหตุการณ์)?

จุดแข็งหลักของ NGINX อยู่ที่... event-driven, non-blocking architectureแทนที่จะสร้างเธรดหรือกระบวนการแยกต่างหากสำหรับแต่ละคำขอ (เหมือนเซิร์ฟเวอร์แบบดั้งเดิม) NGINX ใช้ชุดกระบวนการทำงานขนาดเล็กที่ใช้ลูปเหตุการณ์แบบอะซิงโครนัส แต่ละกระบวนการทำงานสามารถจัดการการเชื่อมต่อได้หลายพันรายการโดยการรอการแจ้งเตือนความพร้อมของระบบปฏิบัติการและประมวลผลเหตุการณ์เมื่อเกิดขึ้น เนื่องจากไม่บล็อกการทำงานของ I/O NGINX จึงสามารถให้บริการเนื้อหาแบบคงที่และแบบพร็อกซีได้โดยใช้ทรัพยากรน้อยที่สุด รูปแบบนี้เหมาะสำหรับกรณีการใช้งานที่มีการทำงานพร้อมกันสูง ทำให้มีประสิทธิภาพมากกว่าเซิร์ฟเวอร์แบบใช้กระบวนการภายใต้ภาระงานหนัก

3) ความแตกต่างหลักระหว่าง NGINX และ Apache คืออะไร?

แม้ว่าทั้ง NGINX และ Apache จะเป็นเว็บเซิร์ฟเวอร์ที่ได้รับความนิยม แต่ก็มีความแตกต่างกันในด้านสถาปัตยกรรม ประสิทธิภาพ และเป้าหมายในการออกแบบ:

แง่มุม	NGINX	อาปาเช่
แบบจำลองความพร้อมกัน	ทำงานโดยอาศัยเหตุการณ์ (แบบอะซิงโครนัส ไม่ปิดกั้น)	กระบวนการทำงาน / การทำงานแบบเธรด (บล็อก)
ใช้หน่วยความจำ	ต้นทุนต่อการเชื่อมต่อต่ำ	สูงขึ้นต่อการเชื่อมต่อ
กรณีใช้งานที่ดีที่สุด	ปริมาณการเข้าชมสูง เนื้อหาคงที่ การกระจายโหลด	เนื้อหาแบบไดนามิกและระบบนิเวศโมดูลที่หลากหลาย
scalability	สามารถขยายขนาดได้ด้วยทรัพยากรที่น้อยลง	ต้องใช้ฮาร์ดแวร์เพิ่มเติมเนื่องจากกระบวนการทำงาน
การจัดการโมดูล	โมดูลที่เลือกในระหว่างการคอมไพล์	ปรับเปลี่ยนได้ตามต้องการขณะรันไทม์

การออกแบบของ NGINX เน้นการเพิ่มประสิทธิภาพภายใต้ภาระงานหนัก ในขณะที่ Apache ให้ความยืดหยุ่นมากกว่าด้วยโมดูลแบบไดนามิกและการรองรับภาษาที่หลากหลาย

4) ส่วนประกอบหลักของไฟล์การกำหนดค่า NGINX มีอะไรบ้าง?

ไฟล์การกำหนดค่า NGINX (เส้นทางเริ่มต้น: /etc/nginx/nginx.conf) ประกอบด้วยบล็อกคำสั่งที่มีโครงสร้างซึ่งกำหนดวิธีการทำงานของ NGINX:

บริบทหลัก: การตั้งค่าทั่วโลก เช่น worker_processes, error_logและ pid
บล็อกกิจกรรม: จัดการการเชื่อมต่อของพนักงานและการประมวลผลแบบหลายโปรเซส
การบล็อก HTTP: ประกอบด้วยการตั้งค่าสำหรับการจัดการ HTTP (การบีบอัด, การแคช, gzip เป็นต้น)
- การบล็อกเซิร์ฟเวอร์: กำหนดโฮสต์เสมือน (โดเมนและพอร์ต)
- บล็อกตำแหน่งที่ตั้ง: กำหนดกฎการกำหนดเส้นทางและวิธีการจัดการ URI เฉพาะต่างๆ

ส่วนประกอบเหล่านี้ทำงานร่วมกันเพื่อกำหนดเส้นทางการร้องขอ กำหนดค่าพร็อกซี และกำหนดค่า SSL/TLS และการแคช

5) คุณจะโหลดการตั้งค่า NGINX ใหม่ได้อย่างปลอดภัยโดยไม่ทำให้ระบบหยุดทำงานได้อย่างไร?

เพื่อรีโหลด NGINX ด้วยการตั้งค่าที่อัปเดตแล้ว without interrupting active connectionsคุณสามารถใช้คำสั่งต่อไปนี้:

nginx -s reload

หรือบนระบบที่ใช้ systemd:

sudo systemctl reload nginx

คำสั่งนี้ส่งสัญญาณไปยังกระบวนการหลักให้ทำการอ่านไฟล์การกำหนดค่าใหม่และรีสตาร์ทกระบวนการทำงานย่อยอย่างราบรื่นโดยไม่ตัดการเชื่อมต่อที่มีอยู่ การรู้วิธีการโหลดซ้ำอย่างราบรื่นเช่นนี้เป็นสิ่งสำคัญในสภาพแวดล้อมที่ต้องการความพร้อมใช้งานสูง

6) อธิบายวิธีการตั้งค่า NGINX ให้เป็นรีเวิร์สพร็อกซี

รีเวิร์สพร็อกซีทำหน้าที่ส่งต่อคำขอของไคลเอ็นต์ไปยังเซิร์ฟเวอร์แบ็กเอนด์ (กลุ่มอัปสตรีม) แล้วส่งการตอบกลับกลับมา ตัวอย่างบล็อกรีเวิร์สพร็อกซีทั่วไปของ NGINX มีดังนี้:

http {
    upstream backend {
        server backend1.example.com;
        server backend2.example.com;
    }

    server {
        listen 80;
        server_name example.com;

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

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

7) อธิบายกระบวนการ Master และ Worker ของ NGINX

ใน NGINX:

การขอ กระบวนการหลัก ทำหน้าที่จัดการการกำหนดค่า เริ่มกระบวนการทำงานของโปรแกรม และจัดการการดำเนินการที่มีสิทธิ์พิเศษ เช่น การผูกพอร์ต
กระบวนการทำงานของพนักงาน ทำหน้าที่จัดการคำขอจริง ๆ เช่น ประมวลผลการเชื่อมต่อขาเข้าและดำเนินการตามกฎที่กำหนดค่าไว้

การทำงานแบบหลายพนักงานช่วยเพิ่มประสิทธิภาพการทำงานพร้อมกัน และสามารถปรับแต่งได้ตามจำนวนคอร์ CPU ที่ใช้งานได้และความต้องการด้านการรับส่งข้อมูล การแบ่งบทบาทช่วยเพิ่มประสิทธิภาพและความเสถียร

8) คุณจะจำกัดการประมวลผลชื่อเซิร์ฟเวอร์ที่ไม่กำหนดไว้ใน NGINX ได้อย่างไร?

เพื่อยกเลิกคำขอที่ไม่มีข้อมูลที่ถูกต้อง Host ส่วนหัวใน NGINX:

server {
    listen 80;
    server_name "";
    return 444;
}

การกำหนดค่านี้จะส่งคืนรหัส 444สถานะที่ไม่เป็นมาตรฐานของ NGINX ซึ่งจะปิดการเชื่อมต่อโดยไม่ได้รับการตอบสนอง ส่งผลให้ปฏิเสธโฮสต์ที่ไม่ระบุไว้ และช่วยเพิ่มความปลอดภัย

9) โมดูล ngx_http_upstream_module ใช้สำหรับอะไร?

การขอ ngx_http_upstream_module กำหนด groups of backend servers (อัปสตรีม) ที่ NGINX สามารถส่งคำขอไปได้โดยใช้คำสั่งต่างๆ เช่น proxy_pass, fastcgi_passหรือ uwsgi_passสิ่งนี้ช่วยให้มีความยืดหยุ่นในการปรับขนาดแอปพลิเคชันในสภาพแวดล้อมที่มีการกระจายโหลด เมื่อมีการจัดกลุ่มเซิร์ฟเวอร์แบ็กเอนด์หลายตัว NGINX สามารถกระจายปริมาณการใช้งานตามนโยบายที่กำหนดไว้ โดยรองรับกลยุทธ์แบบ Round-robin และกลยุทธ์อื่นๆ

10) อธิบายวิธีการใช้ NGINX ในการให้บริการเนื้อหาแบบคงที่และแบบไดนามิก

NGINX มีประสิทธิภาพสูงในการให้บริการ ไฟล์คงที่ (HTML, CSS, รูปภาพ) โดยตรงโดยใช้ลูปเหตุการณ์ที่ได้รับการปรับปรุงและกลไกการอ่านเขียนไฟล์ สำหรับ เนื้อหาแบบไดนามิกNGINX จะส่งคำขอไปยังตัวประมวลผลแบ็กเอนด์ เช่น PHP-FPM Python เซิร์ฟเวอร์ WSGI หรือเฟรมเวิร์กแอปพลิเคชันผ่านกลไก FastCGI/พร็อกซี การแยกส่วนนี้ทำให้ NGINX โดดเด่นในฐานะเซิร์ฟเวอร์ไฟล์แบบคงที่ ในขณะที่ใช้ประโยชน์จากบริการแบ็กเอนด์สำหรับการสร้างแบบไดนามิก เพื่อให้มั่นใจถึงประสิทธิภาพและความสามารถในการขยายขนาดที่ดีที่สุด

11) การกระจายโหลด (Load Balancing) ใน NGINX ทำงานอย่างไร และมีวิธีการใดบ้างที่สามารถใช้งานได้?

NGINX ให้บริการที่แข็งแกร่ง โหลดบาลานซ์ ผ่าน upstream คำสั่งนี้ใช้ในการกระจายปริมาณการใช้งานไปยังเซิร์ฟเวอร์แบ็กเอนด์หลายเครื่องเพื่อเพิ่มประสิทธิภาพและรับประกันความพร้อมใช้งานสูง โดยรองรับวิธีการหลายวิธี:

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

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

12) NGINX โอเพนซอร์ส กับ NGINX Plus แตกต่างกันอย่างไร?

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

ลักษณะ	NGINX โอเพ่นซอร์ส	NGINX พลัส
Load Balancing	พื้นฐาน (รอบคัดเลือกแบบ Round Robin, IP Hash)	ขั้นสูง (ใช้เวลาน้อยที่สุด, การกำหนดค่าใหม่แบบไดนามิก)
การตรวจสอบ	เครื่องมือแบบใช้มือ/ภายนอก	แดชบอร์ดและ API ในตัว
แคช	ขั้นพื้นฐาน	เสริมประสิทธิภาพด้วยระบบควบคุมการชำระล้าง
Support	ชุมชนเท่านั้น	การสนับสนุนและการอัปเดตระดับองค์กร

องค์กรที่มีภาระงานสำคัญมักเลือกใช้ NGINX Plus เนื่องจากมีความน่าเชื่อถือและตรวจสอบได้ดีกว่า

13) คุณใช้งานระบบแคชใน NGINX อย่างไร?

การแคชใน NGINX ช่วยเพิ่มความเร็วในการตอบสนองและลดภาระของแบ็กเอนด์โดยการจัดเก็บเนื้อหาที่เข้าถึงบ่อยไว้ในเครื่อง สามารถเปิดใช้งานได้โดยใช้ proxy_cache คำสั่ง ตัวอย่างการตั้งค่า:

proxy_cache_path /data/nginx/cache levels=1:2 keys_zone=my_cache:10m max_size=1g;
server {
    location / {
        proxy_cache my_cache;
        proxy_pass http://backend;
    }
}

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

14) อธิบายวัตถุประสงค์และการใช้งานของคำสั่ง “try_files”

การขอ try_files คำสั่งนี้จะตรวจสอบว่าไฟล์มีอยู่ตามลำดับที่กำหนดหรือไม่ ก่อนที่จะส่งคำขอไปยังตำแหน่งสำรอง โดยทั่วไปจะใช้เพื่อวัตถุประสงค์ดังต่อไปนี้: การกำหนดเส้นทางไซต์แบบคงที่ or แอปพลิเคชันหน้าเดียว (SPAs).

ตัวอย่าง:

location / {
    try_files $uri $uri/ /index.html;
}

ในกรณีนี้ NGINX จะตรวจสอบก่อนว่า URI ที่ร้องขอตรงกับไฟล์หรือไม่ จากนั้นจึงตรวจสอบว่าตรงกับไดเร็กทอรีหรือไม่ และสุดท้ายจะส่งต่อคำขอที่ไม่ตรงกันไปยังปลายทางอื่น /index.htmlวิธีนี้ช่วยเพิ่มประสิทธิภาพและประสบการณ์การใช้งานของผู้ใช้ โดยการให้บริการไฟล์ที่แคชไว้หรือไฟล์คงที่โดยตรง หลีกเลี่ยงการเรียกใช้งานแบ็กเอนด์โดยไม่จำเป็น

15) NGINX สามารถจัดการกับ HTTPS และการยุติการเชื่อมต่อ SSL/TLS ได้อย่างไร?

NGINX ทำหน้าที่เป็นพร็อกซีสำหรับยุติการเข้ารหัส SSL/TLS โดยจัดการการเข้ารหัสและถอดรหัสที่ระดับเซิร์ฟเวอร์ก่อนที่จะส่งต่อคำขอที่ไม่เข้ารหัสไปยังบริการต้นทาง ตัวอย่างการกำหนดค่า:

server {
    listen 443 ssl;
    server_name example.com;
    ssl_certificate /etc/ssl/certs/example.crt;
    ssl_certificate_key /etc/ssl/private/example.key;
    location / {
        proxy_pass http://backend;
    }
}

จะสนับสนุน HTTP / 2, เย็บเล่ม OCSP, HSTSและ ชุดรหัสลับสมัยใหม่ทำให้การสื่อสารมีความปลอดภัยและมีประสิทธิภาพสูง การยุติการเข้ารหัส SSL ที่ NGINX ช่วยลดภาระการเข้ารหัสบนเซิร์ฟเวอร์แบ็กเอนด์และทำให้การจัดการใบรับรองง่ายขึ้น

16) การเขียนใหม่ (rewrite) และการเปลี่ยนเส้นทาง (redirect) ใน NGINX แตกต่างกันอย่างไร?

ทั้งสอง เขียนใหม่ และ เปลี่ยนเส้นทาง ปรับเปลี่ยนวิธีการส่งต่อคำขอ แต่โดยพื้นฐานแล้วมีความแตกต่างกัน:

แง่มุม	เขียนใหม่	เปลี่ยนเส้นทาง
ประเภท	การเขียน URL ภายในใหม่	การเปลี่ยนเส้นทางไคลเอ็นต์ภายนอก
รหัสตอบกลับ	200 (ภายใน)	301/302 (การเปลี่ยนเส้นทาง HTTP)
แพ็กเกจ	โปร่งใสต่อผู้ใช้	ลูกค้าเห็น URL ใหม่
ใช้กรณี	URL ที่เป็นมิตรต่อ SEO และการกำหนดเส้นทาง	การย้ายโดเมน, การบังคับใช้ HTTPS

ตัวอย่าง:

rewrite ^/oldpage$ /newpage permanent;  # Redirect
rewrite ^/img/(.*)$ /assets/$1 break;   # Rewrite

การเข้าใจความแตกต่างนี้เป็นกุญแจสำคัญในการเพิ่มประสิทธิภาพ SEO และตรรกะการกำหนดเส้นทางอย่างมีประสิทธิผล

17) คุณจะปกป้อง NGINX จากช่องโหว่ทั่วไปได้อย่างไร?

การเสริมความแข็งแกร่งด้านความปลอดภัยนั้นเกี่ยวข้องกับการผสมผสานแนวปฏิบัติที่ดีที่สุดหลายประการ:

ปิดใช้งานโทเค็นเซิร์ฟเวอร์: server_tokens off;
จำกัดวิธีการร้องขอ: อนุญาตเฉพาะคำสั่ง GET, POST และ HEAD เท่านั้น
จำกัดการรั่วไหลของบัฟเฟอร์: กำหนดค่า client_max_body_size และ client_body_buffer_size.
ใช้ HTTPS ร่วมกับระบบเข้ารหัสข้อมูลที่ทันสมัย
เปิดใช้งานการจำกัดอัตรา ผ่านทาง limit_req_zone.
ซ่อนข้อมูลเวอร์ชันและปิดใช้งานการแสดงรายการไดเร็กทอรี

นอกจากนี้ การใช้ก ไฟร์วอลล์แอปพลิเคชันบนเว็บ (WAF) กดไลก์ ModSecurity with NGINX สามารถกรองทราฟฟิกที่เป็นอันตรายได้ การอัปเดต NGINX เป็นประจำและการติดตั้งแพทช์รักษาความปลอดภัยเป็นสิ่งสำคัญในการป้องกันการโจมตีแบบ Zero-day

18) ตัวแปร NGINX คืออะไร และใช้ในการตั้งค่าอย่างไร?

ตัวแปร NGINX เก็บข้อมูลแบบไดนามิกที่ใช้ในการกำหนดค่าและการประมวลผลบันทึก โดยอาจแทนส่วนหัวของคำขอ ที่อยู่ IP ของไคลเอ็นต์ หรือค่าที่คำนวณได้ ตัวอย่างเช่น $remote_addr, $host, $uri, $request_methodและ $upstream_addr.

ตัวอย่างเช่น:

log_format custom '$remote_addr - $host - $uri';

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

19) จะตั้งค่าการจำกัดอัตราการใช้งาน (rate limiting) ใน NGINX ได้อย่างไร?

การจำกัดอัตราการส่งคำขอจะควบคุมความถี่ที่ผู้ใช้สามารถส่งคำขอได้ เพื่อป้องกันการโจมตีแบบ Brute Force และ DDoS โดยจะตั้งค่าโดยใช้ limit_req_zone สั่ง:

limit_req_zone $binary_remote_addr zone=mylimit:10m rate=1r/s;
server {
    location / {
        limit_req zone=mylimit burst=5;
    }
}

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

20) การใช้ NGINX เป็นรีเวิร์สพร็อกซีมีข้อดีและข้อเสียอย่างไรบ้าง?

NGINX ในฐานะรีเวิร์สพร็อกซีมีข้อดีมากมาย แต่ก็มีข้อเสียอยู่บ้างเช่นกัน:

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

ข้อดีของมันมีมากกว่าข้อจำกัดในสถานการณ์ส่วนใหญ่ขององค์กร ทำให้ NGINX เป็นส่วนประกอบที่ขาดไม่ได้ของโครงสร้างพื้นฐานเว็บสมัยใหม่

21) คุณจะตรวจสอบประสิทธิภาพและสถานะของ NGINX ในสภาพแวดล้อมการใช้งานจริงได้อย่างไร?

การตรวจสอบ NGINX เป็นสิ่งสำคัญอย่างยิ่งในการระบุปัญหาคอขวด ความล้มเหลว และพฤติกรรมการรับส่งข้อมูลที่ผิดปกติ สามารถใช้วิธีการต่างๆ ได้ดังนี้:

โมดูลสถานะในตัว (stub_status):
แสดงการเชื่อมต่อที่ใช้งานอยู่ คำขอที่ได้รับการจัดการ และสถานะการอ่าน/เขียน ตัวอย่าง:
```
location /nginx_status {
    stub_status;
    allow 127.0.0.1;
    deny all;
}
```
แดชบอร์ด NGINX Plus: ให้ข้อมูลตัวชี้วัดแบบเรียลไทม์ผ่าน REST API และ GUI
การบูรณาการโดยบุคคลที่สาม: เครื่องมืออย่าง Prometheus, Grafana, Datadog หรือ ELK สามารถรวบรวมข้อมูลเมตริกและบันทึกต่างๆ ได้
บันทึกการเข้าถึงและข้อผิดพลาด: การหมุนเวียนและวิเคราะห์ไฟล์บันทึกอย่างสม่ำเสมอด้วยเครื่องมืออย่าง GoAccess หรือ AWStats ช่วยเพิ่มประสิทธิภาพในการตรวจสอบระบบ

การตรวจสอบช่วยให้มั่นใจได้ถึงความพร้อมใช้งาน การตรวจจับความล้มเหลวอย่างรวดเร็ว และการวางแผนกำลังการผลิต

22) คำสั่ง proxy_pass และ fastcgi_pass แตกต่างกันอย่างไร?

คำสั่งทั้งสองส่งต่อคำขอไปยังบริการแบ็กเอนด์ แต่ได้รับการออกแบบมาสำหรับโปรโตคอลที่แตกต่างกัน:

สั่ง	จุดมุ่งหมาย	โปรโตคอลแบ็กเอนด์	ตัวอย่างการใช้งาน
`proxy_pass`	ส่งต่อคำขอ HTTP หรือ HTTPS ไปยังเซิร์ฟเวอร์แบ็กเอนด์	HTTP	Revการพร็อกซีเว็บ API หรือไมโครเซอร์วิส
`fastcgi_pass`	ส่งคำขอไปยังโปรเซสเซอร์ FastCGI	FastCGI	พีพีพี-เอฟพีเอ็ม Python แอปพลิเคชัน FastCGI

ตัวอย่าง:

location /api/ {
    proxy_pass http://backend;
}
location ~ \.php$ {
    fastcgi_pass unix:/run/php/php7.4-fpm.sock;
}

สรุป ใช้ proxy_pass สำหรับแบ็กเอนด์ HTTP ทั่วไปและ ฟาสต์ซีจี_พาส สำหรับรันไทม์ภาษาแบบไดนามิก เช่น PHP

23) คุณจะตั้งค่าการบีบอัด gzip ใน NGINX ได้อย่างไร และข้อดีของการบีบอัด gzip คืออะไร?

การเปิดใช้งานการบีบอัด Gzip ใน NGINX ช่วยลดการใช้แบนด์วิดท์และปรับปรุงเวลาในการโหลดโดยการบีบอัดข้อความตอบกลับก่อนส่งไปยังไคลเอ็นต์

การกำหนดค่าตัวอย่าง:

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

ประโยชน์ที่ได้รับ:

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

อย่างไรก็ตาม ไม่ควรนำไปใช้กับไฟล์ที่ถูกบีบอัดอยู่แล้ว (เช่น .zip, .jpg, .pngเพื่อหลีกเลี่ยงภาระการทำงานของ CPU ที่มากเกินไป

24) แนวทางปฏิบัติที่ดีที่สุดในการปรับแต่ง NGINX สำหรับปริมาณการใช้งานสูงมีอะไรบ้าง?

การเพิ่มประสิทธิภาพสำหรับพื้นที่ที่มีปริมาณการใช้งานสูงนั้น จำเป็นต้องมีการปรับแต่งทรัพยากรและพารามิเตอร์การกำหนดค่าอย่างรอบคอบ:

พื้นที่	สั่ง	แนวปฏิบัติที่แนะนำ
แรงงาน	`worker_processes auto;`	จับคู่คอร์ CPU
การเชื่อมต่อ	`worker_connections 4096;`	เพิ่มการทำงานพร้อมกัน
ให้มีชีวิตอยู่	`keepalive_timeout 65;`	เพิ่มประสิทธิภาพการใช้งานซ้ำของลูกค้า
เนื้อไม่มีมัน DescriptORS	OS `ulimit -n`	เพิ่มขีดจำกัดสำหรับซ็อกเก็ตที่เปิดอยู่
แคช	`proxy_cache_path`	ลดภาระงานของระบบแบ็กเอนด์
gzip	`gzip on;`	บีบอัดข้อความตอบกลับ

นอกจากนี้ การใช้ การอ่าน/เขียนดิสก์แบบอะซิงโครนัส, โหลดบาลานซ์และ การตรวจสอบสุขภาพต้นน้ำ ช่วยให้มั่นใจได้ถึงเสถียรภาพและความเร็วภายใต้การร้องขอพร้อมกันจำนวนมาก

25) NGINX จัดการการเชื่อมต่อ WebSocket อย่างไร?

WebSockets ช่วยให้การสื่อสารแบบสองทิศทางระหว่างไคลเอ็นต์และเซิร์ฟเวอร์เป็นไปได้ ซึ่งเป็นสิ่งสำคัญสำหรับแอปพลิเคชันแบบเรียลไทม์ NGINX รองรับคุณสมบัตินี้โดยตรงผ่านการส่งต่อส่วนหัวที่ถูกต้อง

การกำหนดค่าตัวอย่าง:

location /ws/ {
    proxy_pass http://backend;
    proxy_http_version 1.1;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection "upgrade";
}

ประเด็นสำคัญ:

การขอ Upgrade และ Connection ส่วนหัวของเอกสารเป็นสิ่งที่จำเป็น
ตรวจสอบให้แน่ใจว่า NGINX ใช้ HTTP/1.1 สำหรับการเชื่อมต่อ TCP แบบถาวร
การกระจายโหลด WebSockets อาจต้องใช้ sticky sessions โดยใช้ ip_hash.

การตั้งค่านี้รองรับแอปพลิเคชันต่างๆ เช่น แชท การซื้อขายหุ้น หรือเกม

26) คำสั่ง “worker_rlimit_nofile” มีวัตถุประสงค์อะไร?

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

worker_rlimit_nofile 100000;

การเพิ่มขีดจำกัดนี้มีความสำคัญอย่างยิ่งสำหรับระบบที่มีการทำงานพร้อมกันสูง (เช่น เกตเวย์ API หรือแพลตฟอร์มสตรีมมิ่ง) อย่างไรก็ตาม ขีดจำกัดของระบบปฏิบัติการ (ulimit -n) จะต้องเพิ่มขึ้นเพื่อให้ตรงกับค่านี้เพื่อความสอดคล้องกันด้วย

27) NGINX สามารถใช้ในการเขียน URL ใหม่หรือเปลี่ยนเส้นทางไปยัง HTTPS โดยอัตโนมัติได้อย่างไร?

การเปลี่ยนเส้นทาง HTTP ไปยัง HTTPS ช่วยให้การสื่อสารมีความปลอดภัย ตัวอย่าง:

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

การกำหนดค่านี้ทำให้เกิดปัญหา การเปลี่ยนเส้นทางถาวร 301 จาก HTTP เป็น HTTPS เพื่อการควบคุมที่ละเอียดกว่านั้น สามารถใช้กฎการเขียนใหม่เพื่อบังคับใช้การเปลี่ยนเส้นทางเฉพาะเส้นทางได้:

rewrite ^/oldpath$ /newpath permanent;

การบังคับใช้ HTTPS โดยอัตโนมัติช่วยปรับปรุงอันดับ SEO ป้องกันการโจมตีแบบ Man-in-the-Middle และรักษาประสบการณ์การใช้งานที่สม่ำเสมอ

28) สาเหตุทั่วไปที่ทำให้เกิดข้อผิดพลาด “502 Bad Gateway” ใน NGINX มีอะไรบ้าง?

ข้อความ "502 Bad Gateway" แสดงว่า NGINX ซึ่งทำหน้าที่เป็นพร็อกซี ไม่สามารถรับการตอบสนองที่ถูกต้องจากเซิร์ฟเวอร์ต้นทางได้ สาเหตุทั่วไป ได้แก่:

เซิร์ฟเวอร์แบ็กเอนด์ล่มหรือไม่สามารถใช้งานได้
ไม่ถูกต้อง proxy_pass URL หรือเส้นทางซ็อกเก็ต
หมดเวลาการเชื่อมต่อต้นทาง (proxy_read_timeout ต่ำเกินไป)
ไฟร์วอลล์หรือ SELinux บล็อกการเชื่อมต่อจากเซิร์ฟเวอร์ภายนอก
ตั้งค่าพารามิเตอร์ FastCGI ไม่ถูกต้อง (สำหรับ PHP)

เพื่อแก้ไขข้อผิดพลาด ให้ตรวจสอบบันทึกข้อผิดพลาด (/var/log/nginx/error.log) ตรวจสอบการเชื่อมต่อกับเซิร์ฟเวอร์ต้นทาง และทดสอบการตอบสนองจากแบ็กเอนด์โดยตรงผ่านทาง curl.

29) NGINX รองรับไมโครเซอร์วิสและสถาปัตยกรรมแบบคอนเทนเนอร์ (เช่น Docker, Kubernetes) อย่างไร?

NGINX เหมาะอย่างยิ่งสำหรับ สภาพแวดล้อมไมโครเซอร์วิส เนื่องจากมีน้ำหนักเบาและมีฟังก์ชันการทำงานแบบรีเวิร์สพร็อกซี ใน Docker หรือ Kubernetes มันทำหน้าที่ดังนี้:

ตัวควบคุมการเข้าถึง: จัดการทราฟฟิก HTTP/S ภายนอกไปยังบริการภายใน
เกตเวย์บริการ: ทำหน้าที่กำหนดเส้นทาง กระจายภาระงาน และตรวจสอบสิทธิ์
พร็อกซีไซด์คาร์: ช่วยเพิ่มความยืดหยุ่นและความสามารถในการตรวจสอบในเครือข่ายบริการ (เช่น Istio)

การกำหนดค่า NGINX สามารถอัปเดตได้แบบไดนามิกผ่าน Kubernetes ConfigMaps ซึ่งช่วยให้สามารถควบคุมการรับส่งข้อมูลและการจัดการ SSL จากส่วนกลางได้ แนวทางแบบโมดูลาร์นี้สอดคล้องอย่างลงตัวกับการใช้งานในรูปแบบคอนเทนเนอร์และคลาวด์เนทีฟ

30) มีวิธีใดบ้างในการปรับปรุงความปลอดภัยของ NGINX สำหรับระบบใช้งานจริง?

การเสริมความปลอดภัยให้กับ NGINX จำเป็นต้องมีการกำหนดค่าหลายระดับ:

การเสริมความแข็งแกร่งให้กับ SSL/TLS: ใช้การเข้ารหัสที่ทันสมัย ปิดใช้งาน SSLv3/TLSv1.0
จำกัดจำนวนเมธอด HTTP: อนุญาตเฉพาะคำกริยาที่ปลอดภัยเท่านั้น (GET, POST, HEAD)

ส่วนหัวด้านความปลอดภัย:

add_header X-Frame-Options "DENY";
add_header X-Content-Type-Options "nosniff";
add_header X-XSS-Protection "1; mode=block";

ซ่อนข้อมูลเวอร์ชัน: server_tokens off;
เปิดใช้งานการจำกัดอัตราและการควบคุมการเข้าถึง
ผสานรวม WAF หรือ Fail2Ban เพื่อป้องกันการโจมตีแบบใช้กำลังดุร้าย

มาตรการเหล่านี้เมื่อรวมกันแล้ว จะสร้างสภาพแวดล้อม NGINX ที่แข็งแกร่งและพร้อมใช้งานจริง ซึ่งสามารถต้านทานช่องโหว่ทั่วไปได้

31) คุณจะแก้ไขปัญหา NGINX อย่างมีประสิทธิภาพได้อย่างไร?

การแก้ไขข้อผิดพลาดของ NGINX เกี่ยวข้องกับการวิเคราะห์บันทึก ไฟล์การกำหนดค่า และสถานะของกระบวนการอย่างเป็นระบบ ขั้นตอนสำคัญได้แก่:

ตรวจสอบไวยากรณ์:

nginx -t

ตรวจสอบความถูกต้องของการตั้งค่าก่อนทำการโหลดใหม่

เปิดใช้งานการบันทึกข้อมูลการแก้ไขข้อผิดพลาด:

error_log /var/log/nginx/error.log debug;

ให้ข้อมูลการวินิจฉัยการทำงานโดยละเอียด

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

tail -f /var/log/nginx/access.log

ทดสอบการเชื่อมต่อ: ใช้ curl -v or wget เพื่อตรวจสอบว่าสามารถเข้าถึงระบบแบ็กเอนด์ได้หรือไม่
ตรวจสอบการเชื่อมต่อที่ใช้งานอยู่: ผ่านทาง stub_status or netstat.

การทำความเข้าใจกระบวนการทำงานของ NGINX ขีดจำกัดของบัฟเฟอร์ และการตอบสนองจากฝั่งเซิร์ฟเวอร์ จะช่วยให้สามารถระบุจุดคอขวดในระบบการผลิตได้อย่างรวดเร็ว

32) คุณตั้งค่าการบันทึกข้อมูลของ NGINX อย่างไร และรูปแบบบันทึกข้อมูลแบบกำหนดเองมีอะไรบ้าง?

NGINX มีกลไกการบันทึกข้อมูลที่ยืดหยุ่นผ่านทาง access_log และ error_log แนวทาง

การกำหนดค่าตัวอย่าง:

log_format main '$remote_addr - $remote_user [$time_local] "$request" '
                '$status $body_bytes_sent "$http_referer" '
                '"$http_user_agent" "$request_time"';

access_log /var/log/nginx/access.log main;
error_log /var/log/nginx/error.log warn;

คุณสามารถกำหนด รูปแบบที่กำหนดเอง เพื่อรวมตัวชี้วัดต่างๆ เช่น $upstream_addr, $request_timeหรือ $bytes_sent.

เพื่อการตรวจสอบขั้นสูง ข้อมูลบันทึกมักถูกส่งไปยัง ELK, Loki หรือ Splunk สำหรับการวิเคราะห์แบบเรียลไทม์และการสร้างแดชบอร์ด

33) บทบาทของคำสั่ง proxy_buffering ใน NGINX คืออะไร?

proxy_buffering ควบคุมว่า NGINX จะบัฟเฟอร์การตอบกลับจากเซิร์ฟเวอร์ต้นทางก่อนส่งไปยังไคลเอ็นต์หรือไม่

การตั้งค่า	Descriptไอออน	ใช้กรณี
`proxy_buffering on;`	Bufferการตอบสนองทั้งหมดเพื่อเพิ่มประสิทธิภาพการประมวลผล	ค่าเริ่มต้น; ช่วยเพิ่มประสิทธิภาพ
`proxy_buffering off;`	ส่งข้อมูลไปยังไคลเอ็นต์โดยตรงโดยไม่ต้องบัฟเฟอร์	การสตรีมแบบเรียลไทม์หรือ API

ตัวอย่างเช่น หากต้องการปิดใช้งานการบัฟเฟอร์:

location /stream/ {
    proxy_buffering off;
}

การปิดใช้งานการบัฟเฟอร์เหมาะสำหรับบริการแชทหรือสตรีมมิ่ง แต่Hอาจลดปริมาณการรับส่งข้อมูลสำหรับเว็บเบราว์เซอร์ทั่วไปได้

34) อธิบายวิธีการยกเลิกหรือล้างแคชของ NGINX

NGINX Open Source ไม่มีฟังก์ชันล้างแคชในตัว แต่สามารถทำได้หลายวิธี:

การล้างด้วยตนเอง: ลบไฟล์ออกจากไดเร็กทอรีแคช
```
rm -rf /var/cache/nginx/*
```
โมดูลจากผู้พัฒนาภายนอก: ใช้ ngx_cache_purge เพื่อล้างข้อมูลผ่านคำขอ HTTP:
```
location ~ /purge(/.*) {
    proxy_cache_purge my_cache $host$1;
}
```
คุณสมบัติของ NGINX Plus: อนุญาตให้ล้างแคชแบบไดนามิกโดยใช้ API

การล้างข้อมูลช่วยให้มั่นใจได้ว่าเนื้อหาที่ล้าสมัยจะถูกแทนที่อย่างรวดเร็ว รักษาความสดใหม่และความสม่ำเสมอของเนื้อหาในระบบ CDN หรือการใช้งานแบบหลายโหนด

35) NGINX จัดการกับปัญหาการหมดเวลาการเชื่อมต่ออย่างไร?

NGINX มีคำสั่งกำหนดเวลาหมดอายุหลายแบบเพื่อควบคุมระยะเวลาที่รอการตอบสนองจากไคลเอ็นต์หรือเซิร์ฟเวอร์ต้นทาง:

สั่ง	จุดมุ่งหมาย	ค่าเริ่มต้น (s)
`client_body_timeout`	ระยะเวลารอสำหรับร่างกายของลูกค้า	60
`client_header_timeout`	ระยะเวลารอสำหรับส่วนหัวของไคลเอ็นต์	60
`keepalive_timeout`	การเชื่อมต่อแบบ keepalive ที่ไม่ได้ใช้งาน	75
`send_timeout`	ถึงเวลาส่งข้อมูลไปยังลูกค้าแล้ว	60
`proxy_read_timeout`	ระยะเวลารอการตอบกลับจากต้นทาง	60

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

36) คุณจะนำการใช้งาน Blue-Green Deployment มาใช้กับ NGINX ได้อย่างไร?

ใน การปรับใช้สีน้ำเงินเขียวโดยมีสภาพแวดล้อมสองแบบ (สีน้ำเงิน = ทำงานอยู่, สีเขียว = สแตนด์บาย) ทำงานพร้อมกัน NGINX ทำหน้าที่เป็นเราเตอร์กระจายสัญญาณระหว่างสภาพแวดล้อมทั้งสอง

การกำหนดค่าตัวอย่าง:

upstream app_cluster {
    server blue.example.com;
    #server green.example.com; # Uncomment during switch
}
server {
    location / {
        proxy_pass http://app_cluster;
    }
}

เมื่อทดสอบและตรวจสอบเวอร์ชันใหม่ (สีเขียว) แล้ว การรับส่งข้อมูลจะถูกสลับโดยการอัปเดตคำจำกัดความอัปสตรีมและโหลด NGINX ใหม่ (nginx -s reload).

วิธีการนี้จะช่วยให้แน่ใจ หยุดทำงานเป็นศูนย์ ระหว่างการอัปเดตหรือย้อนกลับแอปพลิเคชัน

37) การจำกัดอัตราการส่งข้อมูลแบบ Burst คืออะไร และช่วยปรับปรุงประสิทธิภาพของ NGINX ได้อย่างไร?

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

ตัวอย่าง:

limit_req_zone $binary_remote_addr zone=mylimit:10m rate=1r/s;
location /api/ {
    limit_req zone=mylimit burst=5 nodelay;
}

ในกรณีนี้ ระบบจะยอมรับคำขอเพิ่มเติม 5 รายการทันที ก่อนที่จะจำกัดการใช้งาน

เทคนิคนี้ช่วยลดความผันผวนของปริมาณการใช้งาน ทำให้ผู้ใช้ได้รับประสบการณ์ที่สม่ำเสมอโดยไม่ทำให้ระบบแบ็กเอนด์ทำงานหนักเกินไป

38) NGINX จัดการกับ IPv6 และสภาพแวดล้อมแบบ dual-stack อย่างไร?

NGINX รองรับ IPv6 อย่างเต็มรูปแบบทั้งในส่วนเซิร์ฟเวอร์และส่วนอัปสตรีม ตัวอย่างเช่น:

server {
    listen [::]:80 ipv6only=on;
    server_name example.com;
}

การรองรับ Dual-stack (IPv4 + IPv6) ทำได้โดยการรวมทั้งสองอย่างเข้าด้วยกัน:

listen 80;
listen [::]:80;

การรองรับ IPv6 ช่วยให้เข้าถึงได้กว้างขวางยิ่งขึ้น โดยเฉพาะอย่างยิ่งสำหรับอุปกรณ์เคลื่อนที่และผู้ใช้งานในต่างประเทศ และมีความสำคัญอย่างยิ่งต่อการปฏิบัติตามมาตรฐานอินเทอร์เน็ตสมัยใหม่

39) คุณจะตั้งค่า sticky sessions ในการโหลดบาลานซ์ NGINX ได้อย่างไร?

Sticky sessions ช่วยให้มั่นใจได้ว่าคำขอจากไคลเอ็นต์รายเดียวกันจะถูกส่งไปยังเซิร์ฟเวอร์แบ็กเอนด์เดียวกันเสมอ

การใช้ ip_hash:

upstream backend {
    ip_hash;
    server app1.example.com;
    server app2.example.com;
}

คุกกี้แบบเหนียวสำหรับ NGINX Plus:
การรักษาสถานะเซสชันขั้นสูงด้วยคุกกี้ที่สามารถกำหนดค่าได้

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

40) ระดับการบันทึกข้อมูลหลักใน NGINX มีอะไรบ้าง และแต่ละระดับแตกต่างกันอย่างไร?

NGINX รองรับระดับการบันทึกข้อมูลแบบลำดับชั้นเพื่อควบคุมระดับความละเอียดของบันทึกข้อผิดพลาด

ชั้น	Descriptไอออน
`debug`	ข้อมูลโดยละเอียดสำหรับการแก้ไขปัญหา (ละเอียดมาก)
`info`	ข้อมูลเวลาการทำงานโดยทั่วไป
`notice`	เหตุการณ์สำคัญแต่ไม่ถึงขั้นวิกฤต
`warn`	ปัญหาที่อาจเกิดขึ้นหรือการตั้งค่าที่ไม่ถูกต้อง
`error`	Operaข้อผิดพลาดทางภาษาที่ต้องได้รับการแก้ไข
`crit`, `alert`, `emerg`	ข้อผิดพลาดร้ายแรงและการแจ้งเตือนของระบบ

การกำหนดค่าตัวอย่าง:

error_log /var/log/nginx/error.log warn;

การปรับระดับการบันทึกข้อมูลให้เหมาะสมกับสภาพแวดล้อม (ดีบักในสภาพแวดล้อมทดสอบ เตือนในสภาพแวดล้อมใช้งานจริง) ช่วยรักษาสมดุลระหว่างความโปร่งใสและประสิทธิภาพ

41) คุณใช้เกณฑ์ใดในการวัดประสิทธิภาพของ NGINX?

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

ApacheBench (ab):

ab -n 10000 -c 100 http://example.com/

การทดสอบจะตรวจสอบปริมาณคำขอและการทำงานพร้อมกัน
งาน: แสดงค่าเปอร์เซ็นไทล์ความหน่วงและอัตราการร้องขอโดยละเอียด
การปิดล้อม / httperf: จำลองปริมาณการจราจรในโลกแห่งความเป็นจริง
Grafana + Prometheus: ตรวจสอบตัวชี้วัดประสิทธิภาพแบบเรียลไทม์

การเปรียบเทียบมาตรฐานควรวัดพารามิเตอร์ต่างๆ เช่น requests per second (RPS), time per requestและ error rate.

ตัวแปรการปรับแต่ง เช่น worker_processes, worker_connectionsและ keepalive_timeout ช่วยปรับปรุงประสิทธิภาพการทำงานที่สังเกตได้อย่างมีนัยสำคัญ

42) NGINX สามารถทำงานร่วมกับไปป์ไลน์ CI/CD ได้อย่างไร?

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

โครงสร้างพื้นฐานเป็นรหัส (IaC): จัดการการตั้งค่าต่างๆ ด้วย Ansible, Terraform หรือ Helm charts
คอนเทนเนอร์นักเทียบท่า: สร้างและปรับใช้ภาพ NGINX โดยใช้เครื่องมือ CI (Jenkins, GitLab CI หรือ GitHub Actions)
การทดสอบอัตโนมัติ: ตรวจสอบความถูกต้องของการกำหนดค่าโดยใช้ nginx -t อยู่ในขั้นตอนการพัฒนา
สีน้ำเงินเขียว / Canary การทำให้ใช้งานได้อัตโนมัติ: อัปเดตเซิร์ฟเวอร์ต้นทางแบบไดนามิกในระหว่างการเปิดตัว

ตัวอย่างโค้ด GitLab CI:

deploy:
  script:
    - nginx -t
    - systemctl reload nginx

การติดตั้งแบบอัตโนมัติช่วยให้มั่นใจได้ว่าการใช้งาน NGINX จะมีความสม่ำเสมอ ควบคุมเวอร์ชันได้ และเชื่อถือได้

43) อธิบายบทบาทของ NGINX Ingress Controller ใน Kubernetes

การขอ คอนโทรลเลอร์ขาเข้า NGINX ทำหน้าที่จัดการทราฟฟิกขาเข้าสู่บริการ Kubernetes โดยจะแปลงทรัพยากร Kubernetes Ingress ให้เป็นการกำหนดค่า NGINX แบบไดนามิก

ฟังก์ชั่นที่สำคัญ:

ส่งต่อคำขอ HTTP/S ไปยังบริการที่ถูกต้อง
มีฟังก์ชันการยุติ SSL, การจำกัดอัตราการใช้งาน และการเขียน URL ใหม่
รองรับการกระจายโหลดอย่างสมดุลระหว่างพ็อดต่างๆ
อนุญาตให้ใส่คำอธิบายประกอบเพื่อการควบคุมที่ละเอียดกว่า (เช่น เป้าหมายการเขียนใหม่ ขนาดของเนื้อหาพร็อกซี)

ตัวอย่างไฟล์ YAML สำหรับ Ingress:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: web-ingress
  annotations:    nginx.ingress.kubernetes.io/rewrite-target: /
spec:
  rules:
    - host: myapp.example.com
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: web-service
                port:
                  number: 80

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

44) NGINX จัดการกับ HTTP/2 อย่างไร และมีข้อดีอะไรบ้าง?

NGINX รองรับอย่างเต็มที่ HTTP / 2ซึ่งเป็นรุ่นต่อจาก HTTP/1.1 โดยปรับปรุงประสิทธิภาพผ่านการมัลติเพล็กซ์และการบีบอัดส่วนหัว

เพื่อเปิดใช้งาน HTTP/2:

server {
    listen 443 ssl http2;
    ...
}

ข้อดี:

ลักษณะ	Descriptไอออน
Multiplexing	การร้องขอหลายรายการต่อการเชื่อมต่อ TCP เดียว
การบีบอัดส่วนหัว (HPACK)	ลดการใช้แบนด์วิดท์
กดเซิร์ฟเวอร์	ส่งสินทรัพย์ให้ลูกค้าล่วงหน้า
TLS ที่เร็วกว่า	การจับมือที่ปลอดภัยและคล่องตัว

HTTP/2 ช่วยลดความหน่วงและเวลาในการโหลดหน้าเว็บได้อย่างมาก โดยเฉพาะอย่างยิ่งสำหรับเว็บแอปพลิเคชันสมัยใหม่ที่มีส่วนประกอบจำนวนมาก

45) ความแตกต่างระหว่าง upstream keepalive และ connection reuse ใน NGINX คืออะไร?

อัพสตรีมคีปไลฟ์ รักษาการเชื่อมต่อกับเซิร์ฟเวอร์แบ็กเอนด์อย่างต่อเนื่อง ลดภาระการจับมือ (handshake) ของ TCP ตัวอย่างเช่น:

upstream backend {
    server app1.example.com;
    keepalive 32;
}

ความแตกต่าง:

แง่มุม	ให้มีชีวิตอยู่	การใช้การเชื่อมต่อซ้ำ
ขอบเขต	ระหว่าง NGINX และอัปสตรีม	ระหว่าง NGINX และไคลเอ็นต์
จุดมุ่งหมาย	การเพิ่มประสิทธิภาพแบ็คเอนด์	ประสิทธิภาพส่วนหน้า
องค์ประกอบ	`keepalive` ภายใน `upstream`	`keepalive_timeout` in `server` ปิดกั้น

ทั้งสองเทคนิคช่วยลดความหน่วง แต่ใช้ในเลเยอร์การสื่อสารที่แตกต่างกัน (ฝั่งไคลเอ็นต์เทียบกับฝั่งเซิร์ฟเวอร์)

46) คุณจะกำหนดค่า NGINX ใหม่แบบไดนามิกโดยไม่ต้องรีสตาร์ทได้อย่างไร?

เพื่อใช้การตั้งค่าใหม่แบบไดนามิก ไม่มีเวลาหยุดทำงาน, ใช้ reload กลไก:

nginx -t && nginx -s reload

นี่เป็นการส่งสัญญาณว่า กระบวนการหลัก เพื่อสร้างเวิร์กเกอร์ใหม่ที่มีการกำหนดค่าที่อัปเดตแล้ว พร้อมทั้งปิดเวิร์กเกอร์เก่าอย่างนุ่มนวล

ใน NGINX Plus สามารถทำการเปลี่ยนแปลงได้ ผ่าน API (เช่น การเพิ่มเซิร์ฟเวอร์อัปสตรีมแบบไดนามิก):

curl --request POST \
  --url http://localhost:8080/api/3/http/upstreams/backend/servers \
  --header 'Content-Type: application/json' \
  --data-raw '{"server":"10.0.0.12"}'

ความสามารถนี้ช่วยสนับสนุนการปรับใช้โดยไม่ต้องหยุดการทำงานในกระบวนการ DevOps สมัยใหม่

47) ความแตกต่างที่สำคัญระหว่าง Reverse Proxy และ Forward Proxy ใน NGINX คืออะไร?

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

ตัวอย่าง (พร็อกซีส่งต่อ):

location / {
    proxy_pass $scheme://$http_host$request_uri;
    proxy_set_header Host $http_host;
}

Revการใช้พร็อกซีเซิร์ฟเวอร์ยังคงเป็นกรณีการใช้งานหลัก โดยเฉพาะอย่างยิ่งสำหรับเกตเวย์ API และสถาปัตยกรรมไมโครเซอร์วิส

48) NGINX สามารถนำมาใช้ในการจำกัดอัตราการใช้งาน API และการควบคุมการไหลของข้อมูลได้อย่างไร?

การจำกัดอัตราการใช้งานช่วยป้องกันการใช้ API ในทางที่ผิดและรับประกันการใช้งานอย่างเป็นธรรม ตัวอย่างการตั้งค่า:

limit_req_zone $binary_remote_addr zone=api_limit:10m rate=10r/s;
server {
    location /api/ {
        limit_req zone=api_limit burst=20 nodelay;
        proxy_pass http://backend;
    }
}

กลไก:

limit_req_zone: กำหนดโซนหน่วยความจำที่ใช้ร่วมกันและอัตราการใช้งาน
burst: อนุญาตให้มีการเพิ่มขึ้นชั่วคราวในระดับจำกัด
nodelay: บังคับใช้ข้อจำกัดทันที

การกำหนดค่านี้ทำให้มั่นใจได้ว่า IP ของลูกค้าแต่ละรายจะสามารถส่งคำขอได้เพียง 10 คำขอต่อวินาทีเท่านั้น ในขณะที่อนุญาตให้มีการส่งคำขอจำนวนมากในช่วงเวลาสั้นๆ

49) กรณีการใช้งานทั่วไปของ NGINX ในสภาพแวดล้อม DevOps ระดับองค์กรมีอะไรบ้าง?

ในระบบนิเวศ DevOps ระดับองค์กร NGINX มีบทบาทสำคัญหลายประการ:

เว็บเซิร์ฟเวอร์: การส่งมอบเนื้อหาคงที่ประสิทธิภาพสูง
Revพร็อกซี/โหลดบาลานเซอร์ของ erse: การจัดการปริมาณการรับส่งข้อมูลระหว่างไมโครเซอร์วิส
API เกตเวย์: การตรวจสอบสิทธิ์ การกำหนดเส้นทาง และการจำกัดปริมาณการใช้งาน
ตัวควบคุมการเข้าถึง: สำหรับคลัสเตอร์ Kubernetes
ชั้นแคชเนื้อหา: ลดภาระงานของระบบแบ็กเอนด์
จุดสิ้นสุดการยุติ SSL: การจัดการใบรับรองแบบรวมศูนย์
จุดตรวจสอบ: การบูรณาการตัวชี้วัดและการตรวจสอบ

ด้วยขนาดที่เล็กและดีไซน์แบบโมดูลาร์ ทำให้ NGINX เป็นเครื่องมือที่ขาดไม่ได้ในไปป์ไลน์ CI/CD, คลาวด์แบบไฮบริด และคลัสเตอร์ที่มีความพร้อมใช้งานสูง

50) NGINX และ HAProxy มีความแตกต่างหลักๆ อะไรบ้างในเรื่องการกระจายโหลด (load balancing)?

ทั้งสองเป็นอุปกรณ์กระจายโหลดประสิทธิภาพสูง แต่แตกต่างกันที่จุดเน้นและสถาปัตยกรรม:

ลักษณะ	NGINX	HAProxy
บทบาทหลัก	เว็บเซิร์ฟเวอร์ + รีเวิร์สพร็อกซี	ตัวกระจายโหลด TCP/HTTP เฉพาะ
ความเรียบง่ายในการกำหนดค่า	ใช้งานง่ายกว่าสำหรับงานที่เกี่ยวข้องกับเว็บเบราว์เซอร์	การควบคุมที่ซับซ้อนแต่ละเอียดกว่า
การสนับสนุนเลเยอร์	L7 (HTTP), L4 บางส่วน	L4 และ L7 เต็มรูปแบบ
การกำหนดค่าใหม่แบบไดนามิก	มีข้อจำกัด (โอเพนซอร์ส)	การอัปเดตรันไทม์แบบเนทีฟ
ประสิทธิภาพ	เหมาะอย่างยิ่งสำหรับงานที่มีความหลากหลาย	เหนือกว่าในด้านการปรับสมดุลโหลดดิบ
คุณสมบัติเพิ่มเติม	การแคช การบีบอัด เนื้อหาคงที่	การตรวจสุขภาพ, ตารางไม้เรียว

องค์กรต่างๆ มักจะรวมสิ่งต่างๆ เข้าด้วยกัน NGINX (ส่วนหน้า) และ HAProxy (แบ็กเอนด์) เพื่อการกำหนดเส้นทางและการขยายขนาดที่เหมาะสมที่สุด

🔍 คำถามสัมภาษณ์งาน NGINX ยอดนิยม พร้อมสถานการณ์จริงและคำตอบเชิงกลยุทธ์

1) NGINX คืออะไร และเหตุใดจึงนิยมใช้ในสภาพแวดล้อมการผลิต?

สิ่งที่คาดหวังจากผู้สมัคร: ผู้สัมภาษณ์ต้องการประเมินความรู้พื้นฐานของคุณเกี่ยวกับ NGINX และความเข้าใจของคุณเกี่ยวกับคุณค่าเชิงปฏิบัติของมันในระบบจริง

ตัวอย่างคำตอบ: “NGINX เป็นเว็บเซิร์ฟเวอร์และรีเวิร์สพร็อกซีประสิทธิภาพสูง ที่ขึ้นชื่อเรื่องสถาปัตยกรรมแบบขับเคลื่อนด้วยเหตุการณ์ (event-driven architecture) โดยทั่วไปแล้วจะใช้ในสภาพแวดล้อมการผลิต เนื่องจากสามารถจัดการการเชื่อมต่อพร้อมกันจำนวนมากได้อย่างมีประสิทธิภาพ ในขณะที่ใช้ทรัพยากรระบบน้อยกว่าเว็บเซิร์ฟเวอร์แบบดั้งเดิม”

2) คุณช่วยอธิบายความแตกต่างระหว่าง NGINX และ Apache ได้ไหม?

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

ตัวอย่างคำตอบ: “NGINX ใช้สถาปัตยกรรมแบบอะซิงโครนัสและไม่บล็อก ซึ่งทำให้มีประสิทธิภาพมากขึ้นในการจัดการปริมาณการรับส่งข้อมูลสูงและเนื้อหาคงที่ ในขณะที่ Apache ใช้โมเดลที่ขับเคลื่อนด้วยกระบวนการ ซึ่งมีความยืดหยุ่นมากกว่าสำหรับการกำหนดค่าแบบไดนามิก แต่Hอาจใช้ทรัพยากรมากขึ้นภายใต้ภาระงานหนัก”

3) NGINX ทำหน้าที่เป็นรีเวิร์สพร็อกซีได้อย่างไร?

สิ่งที่คาดหวังจากผู้สมัคร: ผู้สัมภาษณ์ต้องการตรวจสอบความเข้าใจของคุณเกี่ยวกับแนวคิดของรีเวิร์สพร็อกซี และวิธีที่ NGINX เข้ากับสถาปัตยกรรมสมัยใหม่

ตัวอย่างคำตอบ: “NGINX ทำหน้าที่เป็นรีเวิร์สพร็อกซี โดยรับคำขอจากไคลเอ็นต์และส่งต่อไปยังเซิร์ฟเวอร์แบ็กเอนด์ จากนั้นจะส่งการตอบกลับจากเซิร์ฟเวอร์กลับไปยังไคลเอ็นต์ ซึ่งช่วยเพิ่มความปลอดภัย การกระจายโหลด และประสิทธิภาพโดยรวม”

4) อธิบายสถานการณ์ที่คุณใช้ NGINX สำหรับการกระจายโหลด (load balancing)

สิ่งที่คาดหวังจากผู้สมัคร: ผู้สัมภาษณ์มองหาประสบการณ์จริงและความสามารถของคุณในการประยุกต์ใช้คุณสมบัติของ NGINX ในสถานการณ์จริง

ตัวอย่างคำตอบ: “ในบทบาทก่อนหน้านี้ ผมได้ตั้งค่า NGINX เพื่อกระจายปริมาณการใช้งานไปยังเซิร์ฟเวอร์แอปพลิเคชันหลายเครื่องโดยใช้อัลกอริทึมแบบ round-robin และ least-connections วิธีนี้ช่วยเพิ่มความพร้อมใช้งานของแอปพลิเคชันและป้องกันไม่ให้เซิร์ฟเวอร์ใดเซิร์ฟเวอร์หนึ่งกลายเป็นคอขวด”

5) คุณจัดการการตั้งค่า SSL และ HTTPS ใน NGINX อย่างไร?

สิ่งที่คาดหวังจากผู้สมัคร: ผู้สัมภาษณ์ต้องการประเมินความเข้าใจของคุณเกี่ยวกับแนวปฏิบัติที่ดีที่สุดด้านความปลอดภัยและการจัดการการกำหนดค่า

ตัวอย่างคำตอบ: “ในตำแหน่งงานก่อนหน้านี้ ฉันได้ตั้งค่า SSL โดยการติดตั้งใบรับรอง เปิดใช้งานตัวรับฟัง HTTPS และบังคับใช้ชุดการเข้ารหัสที่แข็งแกร่ง นอกจากนี้ ฉันยังได้ดำเนินการเปลี่ยนเส้นทาง HTTP ไปยัง HTTPS เพื่อให้มั่นใจได้ถึงการสื่อสารที่ปลอดภัยในทุกปลายทาง”

6) คุณจะดำเนินการอย่างไรเพื่อแก้ไขปัญหาข้อผิดพลาด 502 Bad Gateway ใน NGINX?

สิ่งที่คาดหวังจากผู้สมัคร: ผู้สัมภาษณ์กำลังทดสอบทักษะการแก้ปัญหาและวิธีการแก้ไขปัญหาของคุณ

ตัวอย่างคำตอบ: “ผมจะเริ่มจากการตรวจสอบบันทึกข้อผิดพลาดของ NGINX เพื่อระบุปัญหาการเชื่อมต่อฝั่งเซิร์ฟเวอร์ จากนั้นผมจะตรวจสอบว่าเซิร์ฟเวอร์อัปสตรีมทำงานอยู่หรือไม่ ยืนยันการตั้งค่าพร็อกซีที่ถูกต้อง และตรวจสอบให้แน่ใจว่าได้กำหนดค่าการหมดเวลาอย่างถูกต้องแล้ว”

7) คุณจะเพิ่มประสิทธิภาพการทำงานของ NGINX สำหรับแอปพลิเคชันที่มีปริมาณการใช้งานสูงได้อย่างไร?

สิ่งที่คาดหวังจากผู้สมัคร: ผู้สัมภาษณ์ต้องการทราบว่าคุณมีแนวทางอย่างไรในการปรับแต่งประสิทธิภาพและเพิ่มความสามารถในการขยายขนาด

ตัวอย่างคำตอบ: “ในงานก่อนหน้านี้ ผมได้ปรับปรุงประสิทธิภาพของ NGINX โดยการเปิดใช้งานการบีบอัด gzip ปรับแต่งกระบวนการทำงานของเวิร์กเกอร์ และกำหนดค่าการแคชสำหรับเนื้อหาคงที่ การเปลี่ยนแปลงเหล่านี้ช่วยลดเวลาตอบสนองและภาระของเซิร์ฟเวอร์ได้อย่างมาก”

8) คุณช่วยอธิบายได้ไหมว่า NGINX จัดการกับเนื้อหาแบบคงที่และแบบไดนามิกอย่างไร?

สิ่งที่คาดหวังจากผู้สมัคร: ผู้สัมภาษณ์กำลังประเมินความเข้าใจของคุณเกี่ยวกับการจัดการคำขอและการเพิ่มประสิทธิภาพการทำงาน

ตัวอย่างคำตอบ: “NGINX ให้บริการเนื้อหาคงที่โดยตรงและมีประสิทธิภาพสูงจากระบบไฟล์ สำหรับเนื้อหาแบบไดนามิก มันจะส่งต่อคำขอไปยังเซิร์ฟเวอร์แอปพลิเคชันหรือบริการต่างๆ เช่น PHP-FPM ทำให้แต่ละส่วนประกอบสามารถมุ่งเน้นไปที่สิ่งที่ตนทำได้ดีที่สุด”

9) คุณจัดการและทดสอบการเปลี่ยนแปลงการตั้งค่า NGINX อย่างปลอดภัยได้อย่างไร?

สิ่งที่คาดหวังจากผู้สมัคร: ผู้สัมภาษณ์ต้องการเข้าใจแนวทางของคุณในการสร้างความน่าเชื่อถือและการลดความเสี่ยง

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

10) อธิบายสถานการณ์ที่คุณต้องแก้ไขปัญหาการหยุดชะงักที่เกี่ยวข้องกับ NGINX อย่างรวดเร็ว

สิ่งที่คาดหวังจากผู้สมัคร: ผู้สัมภาษณ์กำลังประเมินความสามารถของคุณในการทำงานภายใต้ความกดดันและการสื่อสารอย่างมีประสิทธิภาพในระหว่างสถานการณ์ต่างๆ

ตัวอย่างคำตอบ: “ในบทบาทล่าสุดของฉัน เกิดเหตุขัดข้องเนื่องจากการตั้งค่าบริการต้นทางไม่ถูกต้อง ฉันได้ระบุปัญหาได้อย่างรวดเร็วผ่านบันทึกข้อมูล ย้อนกลับการตั้งค่า และแจ้งสถานะความคืบหน้าให้ผู้เกี่ยวข้องทราบจนกระทั่งบริการกลับมาใช้งานได้เต็มรูปแบบ”

คำถามและคำตอบสัมภาษณ์งาน Nginx ที่สำคัญที่สุด

1) อธิบายว่า NGINX คืออะไร และเหตุใดจึงมีการใช้งานอย่างแพร่หลายในโครงสร้างพื้นฐานของเว็บ

2) NGINX จัดการคำขอ HTTP ภายในอย่างไร (สถาปัตยกรรมแบบขับเคลื่อนด้วยเหตุการณ์)?

3) ความแตกต่างหลักระหว่าง NGINX และ Apache คืออะไร?

4) ส่วนประกอบหลักของไฟล์การกำหนดค่า NGINX มีอะไรบ้าง?

5) คุณจะโหลดการตั้งค่า NGINX ใหม่ได้อย่างปลอดภัยโดยไม่ทำให้ระบบหยุดทำงานได้อย่างไร?

6) อธิบายวิธีการตั้งค่า NGINX ให้เป็นรีเวิร์สพร็อกซี

7) อธิบายกระบวนการ Master และ Worker ของ NGINX

บทความที่เกี่ยวข้อง

8) คุณจะจำกัดการประมวลผลชื่อเซิร์ฟเวอร์ที่ไม่กำหนดไว้ใน NGINX ได้อย่างไร?

9) โมดูล ngx_http_upstream_module ใช้สำหรับอะไร?

10) อธิบายวิธีการใช้ NGINX ในการให้บริการเนื้อหาแบบคงที่และแบบไดนามิก

11) การกระจายโหลด (Load Balancing) ใน NGINX ทำงานอย่างไร และมีวิธีการใดบ้างที่สามารถใช้งานได้?

12) NGINX โอเพนซอร์ส กับ NGINX Plus แตกต่างกันอย่างไร?

13) คุณใช้งานระบบแคชใน NGINX อย่างไร?

14) อธิบายวัตถุประสงค์และการใช้งานของคำสั่ง “try_files”

15) NGINX สามารถจัดการกับ HTTPS และการยุติการเชื่อมต่อ SSL/TLS ได้อย่างไร?

16) การเขียนใหม่ (rewrite) และการเปลี่ยนเส้นทาง (redirect) ใน NGINX แตกต่างกันอย่างไร?

17) คุณจะปกป้อง NGINX จากช่องโหว่ทั่วไปได้อย่างไร?

18) ตัวแปร NGINX คืออะไร และใช้ในการตั้งค่าอย่างไร?

19) จะตั้งค่าการจำกัดอัตราการใช้งาน (rate limiting) ใน NGINX ได้อย่างไร?

20) การใช้ NGINX เป็นรีเวิร์สพร็อกซีมีข้อดีและข้อเสียอย่างไรบ้าง?

21) คุณจะตรวจสอบประสิทธิภาพและสถานะของ NGINX ในสภาพแวดล้อมการใช้งานจริงได้อย่างไร?

22) คำสั่ง proxy_pass และ fastcgi_pass แตกต่างกันอย่างไร?

23) คุณจะตั้งค่าการบีบอัด gzip ใน NGINX ได้อย่างไร และข้อดีของการบีบอัด gzip คืออะไร?

ประโยชน์ที่ได้รับ:

24) แนวทางปฏิบัติที่ดีที่สุดในการปรับแต่ง NGINX สำหรับปริมาณการใช้งานสูงมีอะไรบ้าง?

25) NGINX จัดการการเชื่อมต่อ WebSocket อย่างไร?

ประเด็นสำคัญ:

26) คำสั่ง “worker_rlimit_nofile” มีวัตถุประสงค์อะไร?

27) NGINX สามารถใช้ในการเขียน URL ใหม่หรือเปลี่ยนเส้นทางไปยัง HTTPS โดยอัตโนมัติได้อย่างไร?

28) สาเหตุทั่วไปที่ทำให้เกิดข้อผิดพลาด “502 Bad Gateway” ใน NGINX มีอะไรบ้าง?

29) NGINX รองรับไมโครเซอร์วิสและสถาปัตยกรรมแบบคอนเทนเนอร์ (เช่น Docker, Kubernetes) อย่างไร?

30) มีวิธีใดบ้างในการปรับปรุงความปลอดภัยของ NGINX สำหรับระบบใช้งานจริง?

31) คุณจะแก้ไขปัญหา NGINX อย่างมีประสิทธิภาพได้อย่างไร?

32) คุณตั้งค่าการบันทึกข้อมูลของ NGINX อย่างไร และรูปแบบบันทึกข้อมูลแบบกำหนดเองมีอะไรบ้าง?

33) บทบาทของคำสั่ง proxy_buffering ใน NGINX คืออะไร?

34) อธิบายวิธีการยกเลิกหรือล้างแคชของ NGINX

35) NGINX จัดการกับปัญหาการหมดเวลาการเชื่อมต่ออย่างไร?

36) คุณจะนำการใช้งาน Blue-Green Deployment มาใช้กับ NGINX ได้อย่างไร?

37) การจำกัดอัตราการส่งข้อมูลแบบ Burst คืออะไร และช่วยปรับปรุงประสิทธิภาพของ NGINX ได้อย่างไร?

38) NGINX จัดการกับ IPv6 และสภาพแวดล้อมแบบ dual-stack อย่างไร?

39) คุณจะตั้งค่า sticky sessions ในการโหลดบาลานซ์ NGINX ได้อย่างไร?

40) ระดับการบันทึกข้อมูลหลักใน NGINX มีอะไรบ้าง และแต่ละระดับแตกต่างกันอย่างไร?

41) คุณใช้เกณฑ์ใดในการวัดประสิทธิภาพของ NGINX?

42) NGINX สามารถทำงานร่วมกับไปป์ไลน์ CI/CD ได้อย่างไร?

43) อธิบายบทบาทของ NGINX Ingress Controller ใน Kubernetes

ฟังก์ชั่นที่สำคัญ:

44) NGINX จัดการกับ HTTP/2 อย่างไร และมีข้อดีอะไรบ้าง?

ข้อดี:

45) ความแตกต่างระหว่าง upstream keepalive และ connection reuse ใน NGINX คืออะไร?

ความแตกต่าง:

46) คุณจะกำหนดค่า NGINX ใหม่แบบไดนามิกโดยไม่ต้องรีสตาร์ทได้อย่างไร?

47) ความแตกต่างที่สำคัญระหว่าง Reverse Proxy และ Forward Proxy ใน NGINX คืออะไร?

48) NGINX สามารถนำมาใช้ในการจำกัดอัตราการใช้งาน API และการควบคุมการไหลของข้อมูลได้อย่างไร?

กลไก:

49) กรณีการใช้งานทั่วไปของ NGINX ในสภาพแวดล้อม DevOps ระดับองค์กรมีอะไรบ้าง?

50) NGINX และ HAProxy มีความแตกต่างหลักๆ อะไรบ้างในเรื่องการกระจายโหลด (load balancing)?

🔍 คำถามสัมภาษณ์งาน NGINX ยอดนิยม พร้อมสถานการณ์จริงและคำตอบเชิงกลยุทธ์

1) NGINX คืออะไร และเหตุใดจึงนิยมใช้ในสภาพแวดล้อมการผลิต?

2) คุณช่วยอธิบายความแตกต่างระหว่าง NGINX และ Apache ได้ไหม?

3) NGINX ทำหน้าที่เป็นรีเวิร์สพร็อกซีได้อย่างไร?

4) อธิบายสถานการณ์ที่คุณใช้ NGINX สำหรับการกระจายโหลด (load balancing)

5) คุณจัดการการตั้งค่า SSL และ HTTPS ใน NGINX อย่างไร?

6) คุณจะดำเนินการอย่างไรเพื่อแก้ไขปัญหาข้อผิดพลาด 502 Bad Gateway ใน NGINX?

7) คุณจะเพิ่มประสิทธิภาพการทำงานของ NGINX สำหรับแอปพลิเคชันที่มีปริมาณการใช้งานสูงได้อย่างไร?

8) คุณช่วยอธิบายได้ไหมว่า NGINX จัดการกับเนื้อหาแบบคงที่และแบบไดนามิกอย่างไร?

9) คุณจัดการและทดสอบการเปลี่ยนแปลงการตั้งค่า NGINX อย่างปลอดภัยได้อย่างไร?

10) อธิบายสถานการณ์ที่คุณต้องแก้ไขปัญหาการหยุดชะงักที่เกี่ยวข้องกับ NGINX อย่างรวดเร็ว

สรุปโพสต์นี้ด้วย:

ลงทะเบียนเพื่อรับจดหมายข่าว