0Pricing
API Gateway & Reverse Proxy (Nginx + Spring Cloud Gateway) · บทเรียน

การตั้งค่า Nginx เบื้องต้น

ทำความเข้าใจโครงสร้างของไฟล์ตั้งค่า Nginx หลักและคำสั่งกำกับที่จำเป็นสำหรับการให้บริการเว็บแบบง่าย

การตั้งค่า Nginx เบื้องต้น เป็นบทเรียน API Gateway & Reverse Proxy (Nginx + Spring Cloud Gateway) ฟรีบน CoddyKit นี่คือบทเรียนที่ 2 จากทั้งหมด 4 บทเรียน คุณสามารถอ่านบทเรียนทั้งหมดด้านล่างฟรี — จากนั้นลองปฏิบัติด้วยตัวคุณเองในเบราว์เซอร์พร้อมตัวแก้ไขโค้ดในตัวและติวเตอร์ AI ตลอด 24/7 บทเรียนนี้เป็นส่วนหนึ่งของเส้นทางการเรียน API Gateway & Reverse Proxy (Nginx + Spring Cloud Gateway) และความก้าวหน้าของคุณจะซิงค์ข้ามเว็บและแอป CoddyKit คอร์ส API Gateway & Reverse Proxy (Nginx + Spring Cloud Gateway) มีบทเรียนทั้งหมด 4 บทเรียน

บางส่วนของบทเรียนนี้ยังไม่ได้รับการแปล และแสดงเป็นภาษาอังกฤษ

Nginx Config: The Blueprint

Nginx uses a simple, yet powerful, configuration file to tell it what to do. Think of this file as the blueprint for your web server.

It defines how Nginx handles requests, serves content, and interacts with other services. Mastering this file is key to using Nginx effectively.

Nginx Config: Main Blocks

Nginx configuration is organized into a hierarchical structure using logical blocks. Each block groups related directives.

  • main: Global settings for the entire Nginx process.
  • events: Settings for how Nginx handles connections.
  • http: The core for all HTTP web server functionalities.

Directives inside these blocks control Nginx's specific behaviors.

user  nginx;
worker_processes  auto;

events {
    # Event context directives
}

http {
    # HTTP context directives
    # ... server blocks go here
}

Global Settings: The `main` Context

The main context contains global directives that affect the entire Nginx process. These are foundational settings for Nginx's operation.

  • user: Defines the user and group that Nginx worker processes run as (e.g., nginx or www-data).
  • worker_processes: Sets the number of worker processes. auto is often a good default, matching your CPU cores.
user  nginx;
worker_processes  auto;
error_log  /var/log/nginx/error.log warn;
pid        /var/run/nginx.pid;

Connection Handling: The `events` Context

The events context configures how Nginx handles network connections. It's about optimizing performance for concurrent clients.

  • worker_connections: The maximum number of simultaneous connections a single worker process can open.

A higher number here allows Nginx to handle more concurrent users efficiently. The use directive (e.g., epoll for Linux) specifies the connection processing method.

events {
    worker_connections  1024;
    use epoll; # Linux-specific, for high performance
}

Web Serving: The `http` Context

The http context is where most of your web server configuration resides. It defines how Nginx processes HTTP requests and responses.

Inside this block, you'll configure things like MIME types, logging, and, most importantly, define individual web servers using server blocks.

http {
    include       mime.types;
    default_type  application/octet-stream;

    sendfile        on;
    keepalive_timeout  65;

    # ... server blocks will be here ...
}

Defining Websites: `server` Blocks

Inside the http block, you define one or more server blocks. Each server block acts like a "virtual host," allowing Nginx to host multiple websites or applications on the same physical server.

It specifies what port Nginx should listen on and for which domain names it should respond.

http {
    server {
        # This is a server block for one website
    }

    server {
        # Another server block for a different site
    }
}

Server Basics: `listen` & `server_name`

Two crucial directives within a server block are listen and server_name. They tell Nginx how to identify and handle requests for a specific website.

  • listen: Specifies the IP address and port number Nginx should listen on (e.g., 80 for HTTP).
  • server_name: Defines the domain names (hostnames) this server block should respond to (e.g., example.com www.example.com).
server {
    listen       80;
    server_name  example.com www.example.com;

    # ... location blocks will be here ...
}

URL Matching: `location` Blocks

Within a server block, location blocks are used to define how Nginx should handle requests for specific URLs or URL patterns.

For instance, you might want to serve static files from one directory for requests to /images/ and handle all other requests differently.

server {
    listen 80;
    server_name mywebsite.com;

    location / {
        # Handle requests to the root path
    }

    location /api/ {
        # Handle requests starting with /api/
    }
}

Serving Files: `root` & `index`

For serving static content like HTML, CSS, and images, root and index are essential directives within a location block.

  • root: Specifies the base directory where Nginx should look for files for requests handled by this location.
  • index: Defines the default file Nginx should serve when a directory is requested (e.g., index.html).

This is how Nginx finds and delivers your website's files.

location / {
    root   /usr/share/nginx/html;
    index  index.html index.htm;
}

Full Example: Static Web Server

Let's put it all together to create a simple Nginx configuration that serves static HTML files from a specific directory.

This configuration listens on port 80 for requests to mywebsite.com and serves files from the /var/www/html directory.

http {
    include       mime.types;
    default_type  application/octet-stream;

    server {
        listen       80;
        server_name  mywebsite.com;

        location / {
            root   /var/www/html;
            index  index.html index.htm;
        }
    }
}

Quick Check: Nginx Directives

Which of the following Nginx directives are typically found within a server block, or within a location block nested inside a server block?

Recap: Nginx Config Basics

Great job! You've learned the fundamental structure of Nginx configuration, including the main, events, http, server, and location blocks.

You can now configure Nginx to listen on specific ports, respond to domain names, and serve static files effectively.

Next, we'll dive into more advanced Nginx features, including how to configure it as a reverse proxy!

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

บทเรียน “การตั้งค่า Nginx เบื้องต้น” ฟรีหรือไม่

ใช่ — ข้อความเต็มของ “การตั้งค่า Nginx เบื้องต้น” ฟรีให้อ่านที่นี่บนเว็บ เพื่อปฏิบัติแบบโต้ตอบ (ตัวแก้ไขโค้ดในตัวและติวเตอร์ AI ตลอด 24/7) และปลดล็อคส่วนที่เหลือของคอร์ส API Gateway & Reverse Proxy (Nginx + Spring Cloud Gateway) ให้อัปเกรดเป็น CoddyKit PRO คอร์ส API Gateway & Reverse Proxy (Nginx + Spring Cloud Gateway) มีบทเรียนทั้งหมด 4 บทเรียน

คุณจะเรียนรู้อะไรในบทเรียน “การตั้งค่า Nginx เบื้องต้น”

ทำความเข้าใจโครงสร้างของไฟล์ตั้งค่า Nginx หลักและคำสั่งกำกับที่จำเป็นสำหรับการให้บริการเว็บแบบง่าย คุณปฏิบัติ API Gateway & Reverse Proxy (Nginx + Spring Cloud Gateway) ด้วยโค้ดที่ใช้งานได้จริงที่คุณเรียกใช้โดยตรงในเบราว์เซอร์ และติวเตอร์ AI ตลอด 24/7 ตอบคำถามของคุณขณะที่คุณไปผ่านบทเรียน

คุณต้องมีประสบการณ์ก่อนที่จะเริ่มเรียน API Gateway & Reverse Proxy (Nginx + Spring Cloud Gateway) หรือไม่

ไม่จำเป็นต้องมีประสบการณ์มาก่อน API Gateway & Reverse Proxy (Nginx + Spring Cloud Gateway) บน CoddyKit ออกแบบมาสำหรับผู้เริ่มต้นไปจนถึงผู้เรียนขั้นสูง คุณสามารถเริ่มต้นที่นี่หรือเริ่มจากตัวแรกและเรียนด้วยความเร็วของคุณเอง นี่คือบทเรียนที่ 2 จากทั้งหมด 4 บทเรียน

บทเรียน “การตั้งค่า Nginx เบื้องต้น” ใช้เวลานานแค่ไหน

บทเรียน CoddyKit ส่วนใหญ่ใช้เวลาประมาณ 5–10 นาที แต่ละบทเรียนจึงสั้นและเป็นแบบโต้ตอบ คุณสามารถก้าวหน้าอย่างต่อเนื่องและกลับมาเรียนต่อจากตรงที่เพิ่งหยุดบนเว็บและแอปได้เลย

ฉันเขียนและรันโค้ดในบทเรียน API Gateway & Reverse Proxy (Nginx + Spring Cloud Gateway) นี้ได้ไหม

ได้ บทเรียน API Gateway & Reverse Proxy (Nginx + Spring Cloud Gateway) ทุกบทมีตัวแก้ไขโค้ดในตัว คุณจึงเขียนและรันโค้ดจริงได้เลยในเบราว์เซอร์ และได้รับข้อเสนอแนะจาก AI ในทันที — ไม่ต้องติดตั้งในเครื่องของคุณ

บทเรียนทั้งหมดในหลักสูตรนี้

  1. การติดตั้งและตั้งค่า Nginx
  2. การตั้งค่า Nginx เบื้องต้น
  3. การให้บริการเนื้อหาแบบคงที่ด้วย Nginx
  4. บล็อก Location ของ Nginx และการจับคู่คำขอ
← กลับไปที่ API Gateway & Reverse Proxy (Nginx + Spring Cloud Gateway)