Apache to nginx Converter: แปลง RewriteRule และ Redirect จาก .htaccess เป็น nginx ได้ในไม่กี่วินาที

ทีมไหนที่เริ่มต้นด้วย Apache ส่วนใหญ่สักวันหนึ่งก็ต้องย้ายไปอยู่บน nginx ไม่ว่าจะเพราะ nginx เป็นค่า default ของโลก container เป็น reverse proxy หลักของการ deploy Node, Python และ PHP-FPM หรือเพราะรับ traffic คอนเคอเรนซีสูง ๆ โดยใช้ memory น้อยกว่ามาก ปัญหาคือ rule ใน .htaccess ที่สะสมมาทั้งหมดจะใช้ต่อไม่ได้เลย เพราะทั้งภาษา ตำแหน่งที่อยู่ และวิธีจับคู่ URL ต่างกันคนละแบบ Apache to nginx Converter เกิดมาเพื่อปิดช่องว่างนี้: paste rule พวก RewriteRule และ Redirect เข้าไป แล้วรับ nginx location block พร้อม return 301 และ rewrite rule กลับออกมาในไม่กี่วินาที

การแปลงนี้ไม่ใช่แค่เปลี่ยน syntax ธรรมดา Apache ประมวลผล rewrite rule แบบ per-directory โดยตัดและใส่ prefix ของ path กลับเข้าไปใหม่ระหว่างทาง ส่วน nginx ประเมินทุกอย่างจาก server-level context เดียวด้วย location block ที่เรียงลำดับกัน ถ้าแปลงมือเปล่า คุณต้องถือ mental model ทั้งสองแบบไว้ในหัวพร้อมกัน แค่พลาดนิดเดียวก็อาจได้ redirect loop หรือ request ที่ควรเป็น 301 กลับถูก proxy ผ่านไปเงียบ ๆ เครื่องมือที่เข้าใจภาษาทั้งสองฝั่งจึงเปลี่ยนงานขุดคุ้ยทั้งบ่าย ให้กลายเป็นการ review ที่ใช้เวลาแค่ห้านาที

ในคู่มือนี้ เราจะพาดูว่าเครื่องมือ parse อะไรได้บ้าง วิธีใช้งานทีละขั้น เหตุผลที่ rule ของสองระบบนี้แปลงแบบหนึ่งต่อหนึ่งไม่ได้ และแนวปฏิบัติที่ทำให้การ migrate server ราบรื่นโดยไม่มีเรื่องน่าปวดหัว

ทำไมต้องใช้ Apache to nginx Converter?

• ทำงานในเบราว์เซอร์ 100% ข้อมูลไม่หลุดออกจากเครื่อง parser ทั้งหมดรัน client-side ด้วย JavaScript rule การ route, hostname ภายใน และ path เก่า ๆ ของคุณไม่เคยถูกส่งขึ้น server ไหนเลย ซึ่งสำคัญมากเมื่อไฟล์ .htaccess มักเผยโครงสร้าง infrastructure ขององค์กรโดยไม่รู้ตัว
• parse ตาม flag ไม่ใช่แค่จับคู่คำ เครื่องมือเข้าใจ [L], [R=301] และ proxy flag [P] รวมถึง Redirect 301 และ RedirectPermanent แล้วแปลงแต่ละตัวไปยังรูปแบบ nginx ที่ถูกต้อง ไม่ใช่ rewrite แบบกากบาง ๆ
• ผลลัพธ์เป็น idiomatic nginx พร้อม paste ใช้ได้เลย redirect กลายเป็น location block พร้อม return 301 rewrite ภายในกลายเป็น rewrite ... permanent; และ rule แบบ proxy กลายเป็น proxy_pass — ตรงตามที่ admin nginx ตัวจริงจะเขียน
• เป็นเครื่องมือสอนที่แอบแฝงมาในรูป converter การเห็น directive ฝั่ง Apache วางเคียงกับ nginx equivalent เป็นวิธีเร่งเรียนรู้ว่า location matching ทำงานอย่างไรที่เร็วที่สุดแบบหนึ่ง และช่วยให้ครั้งหน้าที่ต้องแก้ config เอง คุณทำได้คล่องขึ้น
• ออกแบบมาเพื่อการทำงานซ้ำ ๆ การ migrate จริงเกิดเป็นชุด ๆ: paste สิบ rule แก้ path นิดหน่อย แล้ว paste อีกห้า เครื่องมือตอบสนองทันที วนกี่รอบก็ได้ตามที่ rulebook ของคุณต้องการ
• ฟรี ไม่มีขั้นต่ำ ไม่มี friction ไม่ต้องสมัคร ไม่มี quota ไม่ต้อง install เปิด browser tab วางคู่กับ editor แล้วทำงานต่อได้เลย

คุณสมบัติเด่น

มีสองจุดที่น่าเน้นเป็นพิเศษ หนึ่ง ผลลัพธ์ถูกออกแบบให้ conservative: เมื่อ rule ฝั่ง Apache กำกวม converter จะส่ง nginx equivalent ที่ปลอดภัยที่สุดออกมา พร้อมบรรทัดที่ระบุชัดให้คุณปรับเอง แทนที่จะเดาความตั้งใจของคุณ สอง เพราะทุกอย่างทำงาน local คุณจึง paste rule จาก production config ที่อ้างถึง staging hostname หรือ internal service ได้อย่างสบายใจ — ข้อมูลประเภทที่ไม่ควรส่งผ่าน third-party API

วิธีการใช้งาน

1. รวบรวม rule ทั้งหมด เปิดไฟล์ .htaccess ที่ต้อง migrate ทั้งจาก web root และ subdirectory ต่าง ๆ เพราะ Apache ใช้ไฟล์พวกนี้แบบ per directory แต่ละไฟล์มี rule ของตัวเอง
2. Paste เข้าเครื่องมือ วางบรรทัด directive ลงใน input panel ของหน้า Apache to nginx Converter เครื่องมือจะ parse บรรทัด RewriteRule, Redirect และ RedirectPermanent และข้าม comment กับ directive ที่ไม่เกี่ยวข้อง
3. ตรวจผลลัพธ์ฝั่ง nginx แต่ละ rule จะปรากฏเป็น location block หรือบรรทัด rewrite ลองเช็กว่า match type (prefix, exact หรือ regex) สะท้อนสิ่งที่ rule ฝั่ง Apache ทำจริง
4. คัดลอกเข้า server block นำผลลัพธ์ไปวางใน context server { } ที่เกี่ยวข้องของ nginx config โดยเรียง location block ที่เจาะจงกว่าให้อยู่ในตำแหน่งที่สมเหตุสมผล
5. ทดสอบทุก rule reload nginx (รัน nginx -t ก่อน แล้วค่อย nginx -s reload) แล้วยิง URL เก่าทีละตัวด้วย curl -I เพื่อยืนยันว่าได้ 301 หรือ response แบบ proxy ตามที่คาด ก่อนสลับ traffic จริง

ทำไม rule จึงแปลงแบบ 1:1 ตรง ๆ ไม่ได้

ส่วนนี้คือสิ่งที่ช่วยกัน incident ใน production ได้ Apache กับ nginx แก้ปัญหาเดียวกันคือ URL routing และ rewriting ด้วยสถาปัตยกรรมที่ดูคล้ายกันพอจะเข้าใจผิดว่าใช้แทนกันได้ แต่ต่างกันพอที่จะกัดคุณกลับ

ใน Apache ไฟล์ .htaccess คือ per-directory configuration pattern ของแต่ละ RewriteRule จะจับคู่กับ URL path ที่สัมพันธ์กับ directory นั้น โดย per-directory prefix ถูกตัดและใส่กลับทุกครั้งที่ประเมิน rule rule รันตามลำดับ flag [L] หยุดการประมวลผลรอบปัจจุบัน [R=301] เปลี่ยน rule เป็น external redirect และ [P] ส่งต่อ request ให้ mod_proxy แทนการอ่านไฟล์ เพราะ .htaccess วางได้ใน directory ไหนก็ได้ URL เดียวจึงอาจผ่าน rule หลายชั้นก่อนตัดสินใจขั้นสุดท้าย

nginx ไม่มีแนวคิด per-directory configuration เลย ทุกอย่างอยู่ใน server block (และ location block ที่ซ้อนอยู่ข้างใน) ใน main configuration ที่โหลดตอน startup request หนึ่งจะถูก route เข้า location block เดียว: nginx ลองจับคู่แบบ prefix ก่อน (location /blog/) จากนั้นประเมิน regex location (location ~ pattern แบบ case-sensitive, ~* แบบ case-insensitive) แล้วเลือก match ที่ดีที่สุด ไม่มีการประเมินซ้ำแบบวนลูป — rewrite ... last; จะรีสตาร์ทการจับคู่ location ได้แค่รอบเดียวต่อรอบประมวลผล

ความต่างเหล่านี้นำไปสู่การแมปที่เป็น idiomatic สามแบบ:

• redirect flag กลายเป็น return 301 สำหรับ redirect ธรรมดา return 301 ใน location block ของ nginx ชัดเจนและเร็วกว่า rewrite เพราะจบการประมวลผลทันที
• flag [P] กลายเป็น proxy_pass rule ฝั่ง Apache ที่ proxy ไป backend จะแมปเป็น location block พร้อม directive proxy_pass ที่ชี้ไปยัง upstream
• rewrite ภายในกลายเป็น rewrite rule pattern ที่แปลง URL ก่อนเสิร์ฟ content แมปเป็น directive rewrite ของ nginx พร้อม flag permanent, redirect, last หรือ break ตามพฤติกรรมเดิม

ตัวอย่างการแปลงแบบเทียบข้างกัน:

RewriteEngine On

RewriteRule ^blog/(.*)$ /posts/$1 [R=301,L]
RewriteRule ^api/(.*)$ http://backend:8080/$1 [P]

Redirect 301 /old-page /new-page
RedirectPermanent /legacy /archive

และ nginx equivalent:

rewrite ^/blog/(.*)$ /posts/$1 permanent;

location /api/ {
    proxy_pass http://backend:8080;
}

location = /old-page {
    return 301 /new-page;
}

location = /legacy {
    return 301 /archive;
}

มีสองข้อควรระวังที่ต้องใส่ใจเป็นพิเศษ กอง RewriteCond แปลงตรง ๆ ไม่ได้ เงื่อนไขฝั่ง Apache ผูกกับ RewriteRule ถัดไปและทดสอบ property ของ request เช่น host, query string หรือการมีอยู่ของไฟล์ ใน nginx การเช็กพวกนี้ต้องกลายเป็น logic ระดับ server, map block, try_files หรือ directive if — นั่นคือการออกแบบใหม่ ไม่ใช่การก๊อป การจับคู่แบบไม่สนตัวพิมพ์เปลี่ยนรูปร่าง flag [NC] ของ Apache ไม่มี equivalent ระดับ location คุณต้องใช้ regex location แบบ ~* หรือ normalize ก่อนเข้าถึง ให้ถือว่าทุก rule ที่มีเงื่อนไขซ้อนกันคือสัญญาณให้เทียบพฤติกรรมด้วย request จริง ไม่ใช่แค่เช็ก syntax

กรณีการใช้งานจริง

Migrate host แบบ downtime เป็นศูนย์

สถานการณ์คลาสสิก: คุณกำลังย้ายเว็บจาก VPS ที่รัน Apache ไปเป็น nginx หรือไป managed platform ที่ใช้ nginx อยู่หน้าบ้าน ทุก RewriteRule และ Redirect ใน .htaccess เก่าคือ URL ที่ใครบางคน bookmark ไว้ ลิงก์มา หรือติด index ไว้แล้ว การแปลงทีเดียวทั้งชุดแล้วยืนยันทีละตัวด้วย curl -I ช่วยรักษา SEO equity ที่สะสมมายี่สิบปีให้รอดผ่านวัน cutover

ย้ายแอป PHP เก่าลง container ที่รันหลัง nginx

PHP ใน production อีกจำนวนไม่น้อยยังมาพร้อม .htaccess ที่เขียนไว้เมื่อสิบปีก่อน พอคุณย้ายแอปนั้นลง container ใน container แทบจะรัน PHP-FPM อยู่หลัง nginx เสมอ และไฟล์ .htaccess ก็ถูกมองข้ามทันที converter ช่วยสร้าง nginx equivalent ของ rule เก่าพวกนั้น เพื่อให้ build ใน container ทำงานเหมือนเดิมทุกประการกับ server ตัวที่มันแทนที่

ทำ infrastructure ให้เป็นมาตรฐานเดียวหลัง merger

พอสองบริษัทรวมกัน คุณจะได้ stack มาสองชุด การมาตรฐานบน nginx หมายถึงการแปลง redirect corpus ของอีกฝั่งหนึ่งครั้งเดียวอย่างสะอาด แล้วเก็บผลลัพธ์ไว้ใน version control เป็น single source of truth สำหรับ URL เก่าทุกตัวที่แบรนด์ที่ถูกซื้อเคยเผยแพร่ออกไป

ย้าย redirect ขึ้นไปไว้ที่ edge

สถาปัตยกรรมยุคใหม่ผลักการตัดสินใจ route ไปที่ CDN และ edge worker ซึ่งแพลตฟอร์มเหล่านี้ต้องการ redirect map แบบเรียบ ๆ ไม่ใช่ภาษา Apache การแปลง rule จาก .htaccess ให้เป็นชุด return 301 ที่เรียบร้อยคือก้าวแรกสู่การแยก canonical redirect map ที่คุณโหลดไปใช้ที่ไหนก็ได้ รวมถึงการ generate map file สำหรับระบบขนาดใหญ่

แนวปฏิบัติที่ดี

• ทดสอบทุก rule ด้วย curl -I ไม่ใช่เบราว์เซอร์ เบราว์เซอร์ cache redirect 301 ไว้แรงมาก ส่วน curl -I https://example.com/old-page จะโชว์ status ดิบและ header Location ทุกครั้ง เช็กทั้ง URL เป๊ะ ๆ และตัวย่อยภายใต้ path นั้นด้วย
• เลือก return 301 มากกว่า rewrite สำหรับ redirect ธรรมดา เมื่อไม่ต้องแปลง pattern return ใน location block ถูกกว่า ชัดกว่า และไม่มีทาง loop โดยบังเอิญ
• เก็บ redirect map ไว้ใน version control ผลลัพธ์ nginx ที่ได้คือ asset จริง ๆ commit ไว้ รีวิวผ่าน pull request และให้ CI validate config ด้วย nginx -t ก่อนถึง production
• ระวัง infinite redirect loop rule ที่ส่ง /a ไป /b ขณะที่อีก rule ส่ง /b กลับไป /a — หรือ rewrite ที่ pattern จับคู่กับ substitution ของตัวเอง — จะวนจนกว่า client จะเลิกพยายาม ทดสอบ rule ทั้งสองทิศทางเสมอ
• แปลง logic ของ RewriteCond ด้วยมืออย่างตั้งใจ กองเงื่อนไขคือจุดที่ความเท่ากันแบบอัตโนมัติสิ้นสุด ใช้ nginx primitive ที่ถูกต้อง implement แต่ละเงื่อนไขใหม่ แล้วทดสอบ URL ที่ได้รับผลกระทบซ้ำ
• เรียงลำดับ location block อย่างมีสติ nginx เลือก match ที่ดีที่สุด ไม่ใช่ตัวแรกในลิสต์ แต่ location แบบ prefix กับ regex ที่ทับซ้อนกันยังมีผลต่อกัน จัดกลุ่ม rule ที่เกี่ยวข้องไว้ด้วยกันและใส่ comment กับทุกอย่างที่ลึก

พร้อมก้าวข้ามแล้วหรือยัง? เปิด Apache to nginx Converter paste rule ชุดแรกของคุณ แล้วดู nginx equivalent ภายในไม่กี่วินาที — ไม่ต้อง upload ไม่ต้องสมัคร ไม่ต้องขุด config อีกต่อไป

เครื่องมืออื่น ๆ ที่น่าสนใจ:

• Caddyfile Generator — สร้าง Caddyfile config สำหรับ web server ทางเลือกยุคใหม่
• Redirect Map Generator — สร้าง bulk redirect map และทดสอบการจับคู่ URL สำหรับงาน migrate
• htaccess Generator — สร้าง rule Apache .htaccess สำหรับ redirect, rewrite และ access control

ขอให้ migration ราบรื่น และขอให้ URL เก่าทุกตัวเจอบ้านใหม่ด้วย 301 ที่สะอาดหรี่ — Online Tools Forge Team

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

ถ: Apache to nginx Converter ใช้ฟรีจริงไหม?

ตอบ: ใช่ครับ เครื่องมือทำงานในเบราว์เซอร์ล้วน ๆ ไม่ต้องสมัครสมาชิก ไม่มี quota และไม่มีการประมวลผลฝั่ง server จึงแปลง rule ได้เท่าที่ต้องการ

ถ: ไฟล์ .htaccess ของฉันถูก upload ไปที่ไหนหรือเปล่า?

ตอบ: ไม่ครับ การ parse และสร้างผลลัพธ์ทั้งหมดเกิดขึ้นใน JavaScript บนเครื่องของคุณ rule, hostname และ path ต่าง ๆ ไม่เคยออกจากเครื่องเลย

ถ: เครื่องมือรองรับ directive ฝั่ง Apache แบบไหนบ้าง?

ตอบ: รองรับบรรทัด RewriteRule พร้อม flags ทั้งหมด รวมถึง [L], [R=301] และ proxy flag [P] อีกทั้ง Redirect 301 และ RedirectPermanent ด้วย

ถ: ผลลัพธ์ที่ได้นำไปใช้ใน nginx config ได้เลยโดยไม่ต้องแก้ไหม?

ตอบ: location block, return 301 และ proxy_pass ที่ได้เขียนด้วย syntax มาตรฐานของ nginx แต่ควรตรวจ match type และทดสอบทุก rule ด้วย curl -I ก่อน deploy เสมอ ส่วน RewriteCond ที่ซ้อนซับซ้อนอาจต้องปรับมือเพิ่ม

ถ: เครื่องมือแปลงกลับจาก nginx เป็น Apache ได้ไหม?

ตอบ: converter ทำงานทางเดียวจาก Apache ไป nginx ครับ ถ้าต้องการสร้าง rule .htaccess ใหม่ตั้งแต่ต้น htaccess Generator คือเครื่องมือที่เหมาะกว่า