Rewrite และ .htaccess: ความแตกต่างและข้อควรระวังเมื่อต้องย้ายจาก NGINX และ Apache ไปยัง Caddy บน ServBay

ข้อมูลพื้นฐาน

URL Rewrite (มักเรียกสั้น ๆ ว่า Rewrite หรือการเขียนทับ URL) หรือที่รู้จักในภาษาไทยว่า "การทำ URL เสมือน" คือเทคนิคระดับเซิร์ฟเวอร์ที่ช่วยปรับเปลี่ยน URL ของคำขอแบบไดนามิก ตัวอย่างเช่น การเปลี่ยน /?page=123 ให้กลายเป็น /posts/123/ โดยที่ผู้ใช้จะเห็น URL ที่สวยงามในแถบที่อยู่เบราว์เซอร์เท่านั้น โดยเบื้องหลังเว็บเซิร์ฟเวอร์จะทำงานกับ URL ที่ถูกกำหนดใหม่ เทคโนโลยีนี้ถูกนำไปใช้กับจุดประสงค์หลายอย่าง อาทิ

• ปรับโครงสร้าง URL ให้สวยงาม: ได้ URL ที่อ่านง่าย จดจำง่าย และแชร์ต่อได้ง่าย ("Clean URL")
• เสริม SEO: ช่วยให้เสิร์ชเอนจินจัดอันดับได้ดีขึ้น เพราะ URL มีความหมายและเป็นระบบ
• ซ่อนรายละเอียดภายใน: ช่วยซ่อน path ไฟล์หรือพารามิเตอร์ เพื่อเสริมความปลอดภัย
• กำหนดมาตรฐานรูปแบบ URL: เช่น บังคับใช้ www, บังคับ https ฯลฯ
• ทำระบบ Routing: หลายเฟรมเวิร์กใช้ Rewrite เพื่อส่งทุก request ไปยัง entry point เดียว (เช่น index.php) เพื่อให้ framework รับจัดการต่อ

การเข้าใจและตั้งค่า Rewrite rule ถือเป็นทักษะพื้นฐานที่สำคัญของนักพัฒนาเว็บ

ServBay รองรับ NGINX และ Apache

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

ศึกษาการสลับเซิร์ฟเวอร์หลักได้ที่เอกสาร: วิธีตั้งค่า Web Server หลัก

ServBay มอบตัวเลือกเซิร์ฟเวอร์ยอดนิยมหลายค่าย ไม่ว่าจะเป็น Caddy, NGINX, และ Apache เพื่อให้งานติดตั้งและปรับแต่งสภาพแวดล้อม local development ง่ายขึ้น ServBay ได้ตั้งค่า Rewrite rule ที่จำเป็นสำหรับ Caddy และ NGINX มาให้ล่วงหน้า ครอบคลุมความต้องการของเฟรมเวิร์กและ CMS สมัยใหม่ส่วนใหญ่ หมายความว่าโปรเจกต์ยอดนิยมที่ใช้ PHP อย่าง WordPress, Laravel, Symfony ฯลฯ เมื่อรันบน ServBay จะ "พร้อมใช้งานทันที" โดยไม่ต้องแก้ config เพิ่มเติม

แต่สำหรับนักพัฒนาที่คุ้นเคยกับ Apache หรือ NGINX แล้วต้องการ หรือกำลังจะย้ายเว็บหรือโปรเจกต์เดิมมารันบน Caddy (ที่มากับ ServBay) สิ่งสำคัญคือคุณต้องเข้าใจความแตกต่างเรื่อง Rewrite rule ของแต่ละตัว เอกสารฉบับนี้จะอธิบายจุดต่าง ระหว่าง Apache, NGINX, และ Caddy ทั้งในแง่แนวทาง ตลอดจนข้อควรระวังเมื่อต้องย้าย config

กฎ Rewrite "พร้อมใช้" : จุดเด่นของ ServBay

ข้อควรระวังสำคัญ

หนึ่งในเป้าหมายสำคัญของ ServBay คือการลดความซับซ้อนและเวลาในการติดตั้ง local environment สำหรับแอปและเฟรมเวิร์กยอดนิยม ServBay มี Rewrite rule ที่พร้อมใช้งานอยู่แล้ว คุณแทบไม่ต้องเซ็ตหรือเขียน Rewrite เพิ่มเองเลย

ถ้าคุณกำลังย้ายเว็บ/โปรเจกต์จาก Apache หรือ NGINX มารันบน Caddy ของ ServBay และมี Rewrite rule พิเศษหรือซับซ้อน จำเป็นต้องดูรายละเอียดจากคู่มือการย้ายต่อไปนี้:

• การย้ายเว็บไซต์ NGINX มายัง ServBay (Caddy)
• การย้ายเว็บไซต์ Apache มายัง ServBay (Caddy)

แนะนำ Rewrite rule ของ Web Server ต่าง ๆ

แต่ละเว็บเซิร์ฟเวอร์มีรูปแบบ config สำหรับ Rewrite ที่ไม่เหมือนกัน การเข้าใจโครงสร้างเหล่านี้จะช่วยให้ migration ข้ามระบบเป็นไปอย่างมีประสิทธิภาพ ส่วนนี้จะทบทวนแนวทางของ Apache, NGINX และ Caddy อย่างคร่าว ๆ

ไฟล์ .htaccess ของ Apache

Apache HTTP Server ใช้ไฟล์ .htaccess กำหนด Rewrite rule แบบกระจาย (distributed config) โดยมักวางไว้ที่ root ของเว็บไซต์หรือในโฟลเดอร์ย่อยใด ๆ สามารถ override config หลักเฉพาะ directory นั้น ๆ ได้ (ถ้าโฟลเดอร์ลูกมี .htaccess ของตัวเอง) Apache จะใช้โมดูล mod_rewrite เพื่อจัดการ Rewrite rule

ตัวอย่างการใช้งานพื้นฐาน

ตัวอย่างนี้ คือ .htaccess ที่นิยมใช้ ให้ redirect คำขอไปยัง index.php เมื่อไม่พบไฟล์หรือโฟลเดอร์บน server ซึ่งเป็นวิธีที่พบได้ในหลาย PHP framework และ CMS

# เปิดใช้งาน Rewrite Engine
RewriteEngine On

# ถ้าไม่ใช่ไฟล์หรือโฟลเดอร์จริง ให้ใช้ Rewrite rule นี้
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d

# เขียนทับทุก request ไปที่ index.php (พร้อม query string เดิม)
RewriteRule ^(.*)$ index.php [L,QSA]

อธิบาย

• RewriteEngine On: เปิดใช้งาน rewrite ใน directory นี้
• RewriteCond %{REQUEST_FILENAME} !-f: เช็กว่า path ที่ร้องขอ (%{REQUEST_FILENAME}) ไม่ใช่ไฟล์ที่มีอยู่จริง (!-f)
• RewriteCond %{REQUEST_FILENAME} !-d: เช็กว่า path ที่ร้องขอ ไม่ใช่โฟลเดอร์ที่มีอยู่จริง (!-d)
• RewriteRule ^(.*)$ index.php [L,QSA]:
  • ^(.*)$: ตรงกับทุก path ของ URL
  • index.php: เขียนทับ path ให้ไปที่ index.php
  • [L]: หยุดที่ rule นี้
  • [QSA]: ต่อ query string จาก URL เดิมไปยัง URL ใหม่นี้

รูปแบบ Rewrite Rule ของ NGINX

NGINX จะจัดการ Rewrite ผ่านไฟล์หลัก (nginx.conf) หรือไฟล์ config ของแต่ละเว็บไซต์ (ปกติอยู่ใน conf.d, sites-available หรือ sites-enabled) มักกำหนด rule ไว้ภายใต้ server block (virtual host) หรือ location block (กำหนด path ย่อย) โมดูลที่เกี่ยวข้องคือ ngx_http_rewrite_module ซึ่ง syntax แตกต่างจาก Apache

ตัวอย่างการใช้งานพื้นฐาน

ด้านล่างคือ config ตัวอย่างของ NGINX สำหรับ logic การเขียนทับคำขอไป index.php เช่นเดียวกับตัวอย่างด้านบน

server {
    listen 80;
    server_name servbay.demo; # ตัวอย่างโดเมนของ ServBay

    root /Applications/ServBay/www/demo; # Path root เว็บ

    # ลำดับความสำคัญ: หาไฟล์, โฟลเดอร์, ถ้าไม่มีให้ rewrite ไป index.php
    location / {
        try_files $uri $uri/ /index.php?$query_string;
    }

    # จัดการ request ไป .php ด้วย PHP-FPM/FastCGI
    location ~ \.php$ {
        # เช็กว่าไฟล์มีจริง ป้องกันการ execute ไฟล์ไม่พึงประสงค์
        try_files $uri =404;
        include fastcgi_params;
        # ที่อยู่ Socket PHP FastCGI ที่ ServBay กำหนดไว้
        fastcgi_pass unix:/Applications/ServBay/tmp/php-cgi.sock;
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
    }
}

อธิบาย

• location /: ตรงกับ request ที่ root domain
• try_files $uri $uri/ /index.php?$query_string;:
  1. ตรวจสอบว่าไฟล์ที่ร้องขอใน URI มีอยู่จริงหรือไม่ ($uri)
  2. ตรวจสอบว่ามีโฟลเดอร์ตาม URI หรือไม่ ($uri/)
  3. ถ้าไม่มีทั้งไฟล์และโฟลเดอร์ ให้ rewrite ไปที่ /index.php โดยแนบ query string เดิม (?$query_string)
• location ~ \.php$: ทุก request ที่ลงท้ายด้วย .php
• fastcgi_pass unix:/Applications/ServBay/tmp/php-cgi.sock;: ส่ง request PHP ไปยังตัวประมวลผล PHP FastCGI ที่ ServBay ตั้งไว้

การกำหนด Rewrite Rule ใน Caddy

Caddy ใช้ไฟล์ config ชื่อว่า Caddyfile เน้นความกระชับ, อ่านง่าย และทรงพลัง Syntax ของ Caddyfile แตกต่างจาก Apache หรือ NGINX มาก แต่ใช้ง่ายกว่าเดิม Rewrite rule บน Caddy ใช้คำสั่ง rewrite และ matcher ที่ยืดหยุ่น

ตัวอย่างการใช้งานพื้นฐาน

ตัวอย่างข้างล่างนี้คือ Caddyfile ที่ให้ logic เหมือน Apache/NGINX ด้านบน

servbay.demo { # ตัวอย่างโดเมนของ ServBay
    root * /Applications/ServBay/www/demo # Path root เว็บ

    # ส่งคำขอ .php ไปยัง PHP FastCGI ของ ServBay โดยตรง
    php_fastcgi unix//Applications/ServBay/tmp/php-cgi.sock

    # ให้ Caddy เสิร์ฟไฟล์ static
    file_server

    # สร้าง matcher @notStatic : ถ้าไม่มีไฟล์/โฟลเดอร์ตามที่ร้องขอ
    @notStatic {
        not {
            file {
                # ลองหาไฟล์ {path} หรือโฟลเดอร์ {path}/
                # ถ้าไม่มีจะ trigger matcher @notStatic
                try_files {path} {path}/
            }
        }
    }

    # ถ้า @notStatic เป็นจริง rewrite ไป /index.php
    rewrite @notStatic /index.php
}

อธิบาย

• servbay.demo { ... }: สร้าง site block สำหรับโดเมนนี้
• root * /Applications/ServBay/www/demo: กำหนด root เว็บไซต์ให้ใช้กับทุก path
• php_fastcgi unix//Applications/ServBay/tmp/php-cgi.sock: direct ว่า request .php ให้ไปยัง PHP FastCGI ของ ServBay
• file_server: ให้เสิร์ฟไฟล์ static
• @notStatic { ... }: สร้าง matcher ชื่อ notStatic
• not { file { try_files {path} {path}/ } }: ถ้า path ที่ขอไม่มีไฟล์หรือโฟลเดอร์จริง จะถือว่า matcher นี้เป็น true
• rewrite @notStatic /index.php: ถ้า matcher เป็นจริงจะ rewrite ไป /index.php

ใน Caddy config ที่ ServBay ให้มาโดย default คำสั่ง php_fastcgi ได้ครอบคลุม logic try_files เรียบร้อยแล้ว และ ServBay จะสร้าง Caddyfile พื้นฐานให้อัตโนมัติเมื่อมีเว็บใหม่ ทำให้หลาย framework ใช้ได้ทันที ตัวอย่างด้านบนนี้ไว้เพื่ออธิบาย structure ที่แท้จริงของ Caddy

ข้อควรระวังเมื่อต้องย้ายจาก Apache หรือ NGINX ไปยัง Caddy ของ ServBay

ระหว่างการย้ายเว็บจาก Apache หรือ NGINX ไปสู่ Caddy ใน ServBay เรื่องสำคัญคือการแปลง Rewrite rule แม้ ServBay จะตั้งค่าพื้นฐานให้แล้ว แต่หากเว็บไซต์หรือโปรเจกต์ของคุณมี rule พิเศษ จะต้องแปลงด้วยตนเอง

ดูกลยุทธ์และแนวทางได้จากเอกสารต่อไปนี้:

• การย้ายเว็บไซต์ Apache มายัง ServBay (Caddy)
• การย้ายเว็บไซต์ NGINX มายัง ServBay (Caddy)

ประเด็นสำคัญที่ต้องให้ความสนใจ มีดังนี้:

1. Syntax และตำแหน่งของ Rewrite Rule

   • Apache: ใช้ .htaccess (distributed, ที่ directory ไหนก็ได้) หรือ config หลัก (httpd.conf หรือ site config) โดย syntax ยึด regex
   • NGINX: Configs อยู่ในไฟล์กลาง (nginx.conf หรือไฟล์เว็บ) Syntax ต่างจาก Apache เน้นใช้ location, rewrite, if และ try_files
   • Caddy: ใช้ Caddyfile (รวมศูนย์กลาง) โดย config จะอยู่ในแต่ละ block site ใช้ matcher ที่ยืดหยุ่น อ่านง่ายกว่า
   • การแปลง: คุณจะต้องถอด config จาก Apache (.htaccess) หรือ NGINX (location/rewrite/try_files) แล้วเขียนใหม่เป็นภาษา Caddy ไม่มี tool ที่แปลงให้ตรง ๆ เสมอไป จำเป็นต้องศึกษา matcher และ rewrite ของ Caddy เพิ่มอีกเล็กน้อย

2. รูปแบบโครงสร้างไฟล์ Config

   • Apache: กระจายตาม directory (ผ่าน .htaccess) หรือรวมไว้ที่ main config แล้วแยก vhost
   • NGINX: อยู่รวมที่ nginx.conf และ site config ใน directory ของ server และ location
   • Caddy: ทุกอย่างอยู่ที่ Caddyfile โดยแบ่งแต่ละเว็บไซต์เป็น block

3. โมดูลและคำสั่งเทียบเคียง

   • Apache และ NGINX มี module และ directive หลากหลาย ฝั่ง Caddy ก็มีฟังก์ชันครบแต่โครงสร้างกับชื่อคำสั่งเปลี่ยนไป เช่น mod_rewrite (Apache) ใช้ rewrite matcher ใน Caddy, try_files (NGINX) ก็มีใน Caddy แบบ matcher หรือใน php_fastcgi
   • ควรค้นหาตาม documentation ของ Caddy ว่าคำสั่งไหนแทนฟังก์ชันเดิมได้

4. พฤติกรรมตั้งต้นและลำดับความสำคัญต่างกัน

   • Apache อ่าน .htaccess ตาม directory NGINX มีลำดับความสำคัญตาม block ต่างๆ ส่วน Caddy รันและอ่านตามบล็อกและตามลำดับของ Caddyfile
   • ควรทดสอบ URL ทุกแบบหลัง migration ให้แน่ใจว่า Rewrite rule ยังทำงานถูกต้อง และตรวจสอบด้วยว่า Caddy config แบบ pre-set ของ ServBay อาจเขียน rule ที่ซ้ำหรือขัดแย้งกับของคุณเองหรือเปล่า

สรุป

ServBay มอบ 3 ตัวเลือกเว็บเซิร์ฟเวอร์ยอดนิยม ทั้ง Caddy, NGINX และ Apache ภายใต้ระบบเดียว สำหรับ Caddy และ NGINX ServBay ตั้งค่า Rewrite rule พื้นฐานให้แล้ว (พร้อมใช้กับ framework และ CMS หลายตัว) แต่หากคุณชินกับ config แบบ Apache/NGINX และจะย้ายมาใช้ Caddy จำเป็นต้องเข้าใจความต่างเรื่อง Rewrite rule

• Apache ใช้ .htaccess กับ RewriteRule/RewriteCond แบบกระจาย
• NGINX ใช้ config รวมศูนย์ โดยแนวคิดอยู่ที่ location, rewrite, try_files
• Caddy เรียบง่ายกว่า ใช้ Caddyfile กับ syntax คล่องตัวและ matcher แบบใหม่

หัวใจของการย้ายอยู่ที่การเปลี่ยน logic ของ Apache/NGINX Rewrite ให้มาอยู่ในภาษาของ Caddyfile ถึงแม้จะต้องทำความเข้าใจและแปลงเองบ้าง (ไม่มี one-to-one tool ที่สมบูรณ์) แต่ด้วย config ที่กระชับ บวกกับคู่มือ โดย ServBay การตั้งค่าและ migration จะง่ายขึ้นมาก หวังว่าเอกสารนี้จะช่วยให้คุณเข้าใจความต่าง และทำงาน local development บน ServBay ได้อย่างคล่องตัว