เว็บนี้มีลิงก์ affiliate — หากสมัครผ่านลิงก์ เราได้รับค่าคอมมิชชัน · Affiliate links. รายละเอียด

คู่มือ .htaccess 2026 ทำอะไรได้บ้าง ตัวอย่าง Code ที่ใช้บ่อย

.htaccess Guide 2026: What It Does and the Most Useful Code Examples

คู่มือ .htaccess 2026 ทำอะไรได้บ้าง ตัวอย่าง Code ที่ใช้บ่อย

.htaccess คืออะไร ทำงานอย่างไรบน Apache

.htaccess (Hypertext Access) คือไฟล์ configuration ของ Apache Web Server ที่ช่วยให้เจ้าของเว็บไซต์สามารถปรับแต่งพฤติกรรมของ server ได้ในระดับ directory โดยไม่ต้องแก้ไขไฟล์ configuration หลักอย่าง httpd.conf และไม่ต้อง restart server ทุกครั้งที่มีการเปลี่ยนแปลง

ชื่อไฟล์ขึ้นต้นด้วยจุด (.htaccess) ทำให้เป็นไฟล์แบบ hidden บนระบบ Unix/Linux ซึ่งซ่อนอยู่โดยค่าเริ่มต้น Apache จะอ่านไฟล์ .htaccess ทุกครั้งที่มี HTTP request เข้ามา โดยเริ่มจาก root directory ไล่ลงมาจนถึง directory ที่ไฟล์ที่ร้องขออยู่ ทำให้การแก้ไขมีผลทันทีโดยไม่มี downtime

การทำงานของ .htaccess นั้นขึ้นอยู่กับ directive AllowOverride ใน httpd.conf ซึ่ง server admin จะต้องเปิดใช้งานก่อน ค่าที่นิยมใช้คือ AllowOverride All สำหรับ shared hosting ส่วนใหญ่จะเปิดไว้ให้แล้วโดยอัตโนมัติ

สิ่งที่ .htaccess ทำได้มีมากมาย ได้แก่ การ redirect URL, การบังคับ HTTPS, การป้องกันไฟล์ด้วย password, การ block IP, การตั้ง cache headers, การสร้าง custom error page, การป้องกัน hotlinking รูปภาพ, การ rewrite URL ให้สวยงาม (Pretty URL), และการตั้งค่า PHP ผ่าน php_value

วิธีสร้างไฟล์ .htaccess: สร้างไฟล์ text ธรรมดา ตั้งชื่อว่า .htaccess (มีจุดนำหน้า ไม่มีนามสกุลต่อท้าย) แล้ววางไว้ใน root directory ของเว็บไซต์ หรือ subdirectory ที่ต้องการควบคุมเฉพาะ กฎที่อยู่ใน directory ย่อยจะมีผลเฉพาะในนั้นและ directory ย่อยที่อยู่ภายใน แต่จะไม่ขึ้นไปมีผลใน directory ที่สูงกว่า

# ตัวอย่าง .htaccess เบื้องต้น — เปิด mod_rewrite
Options +FollowSymLinks
RewriteEngine On

# แสดงไฟล์ index แทนการแสดง directory listing
DirectoryIndex index.php index.html index.htm

ข้อสำคัญ: .htaccess รองรับเฉพาะ Apache เท่านั้น หากเว็บไซต์ของคุณใช้ Nginx (ซึ่งนิยมมากขึ้นเรื่อย ๆ) หรือ IIS บน Windows จะต้องใช้วิธีการตั้งค่าที่แตกต่างออกไปและ .htaccess จะไม่มีผลใด ๆ

การ redirect URL และ 301 Redirect ด้วย .htaccess

การ redirect URL ผ่าน .htaccess เป็นหนึ่งในการใช้งานที่พบบ่อยที่สุด ไม่ว่าจะเป็นการย้าย URL เก่าไปยัง URL ใหม่, การ redirect ทั้งโดเมน, หรือการส่งผู้ใช้ไปยังหน้าที่ถูกต้องเมื่อมีการพิมพ์ผิด

301 Redirect (Permanent) บอก search engine ว่า URL นี้ย้ายถาวรแล้ว ให้อัปเดต index และส่ง link equity ไปยัง URL ใหม่ เหมาะสำหรับการ redesign เว็บ, การย้าย domain, หรือการเปลี่ยน URL structure ถาวร

302 Redirect (Temporary) บอก search engine ว่าย้ายชั่วคราว ให้เก็บ URL เดิมไว้ใน index เหมาะสำหรับการทดสอบ A/B หรือหน้า maintenance ชั่วคราว

# 301 Redirect — URL เดียว (ถาวร)
Redirect 301 /old-page.html /new-page.html

# 302 Redirect — ชั่วคราว
Redirect 302 /promo /sale

# Redirect ทั้ง directory พร้อมเนื้อหา
Redirect 301 /blog/ /articles/

# Redirect ไปยัง domain อื่น
Redirect 301 /partner https://example.com/partner

# 301 ด้วย mod_rewrite — แบบยืดหยุ่นกว่า (รองรับ regex)
RewriteEngine On
RewriteRule ^old-page\.html$ /new-page.html [R=301,L]

# Redirect pattern ทั้งหมดใน /products/ ไป /shop/
RewriteRule ^products/(.*)$ /shop/$1 [R=301,L]

# Redirect URL ที่มี query string
RewriteCond %{QUERY_STRING} ^id=123$
RewriteRule ^page\.php$ /new-page.html? [R=301,L]

เมื่อ redirect แบบ chain (ต่อ ๆ กัน) ควรระวัง redirect loop เช่น A → B → A ซึ่งจะทำให้เบราวเซอร์แสดง error "Too many redirects" และทั้ง user และ search engine จะไม่สามารถเข้าถึงหน้านั้นได้ ควรตรวจสอบด้วยเครื่องมือ เช่น Redirect Checker ก่อน deploy จริง

Flag [L] ใน mod_rewrite หมายถึง "Last" — หยุดประมวลผล rule ถัดไป ส่วน [R=301] หมายถึง redirect ด้วย HTTP status 301 การใส่ทั้งสองค่าพร้อมกัน ([R=301,L]) คือ pattern ที่ถูกต้องและใช้บ่อยที่สุด

บังคับ HTTPS และ www redirect ด้วย .htaccess

ในปี 2026 การบังคับให้เว็บไซต์ใช้ HTTPS เป็นมาตรฐานที่ขาดไม่ได้ Google ใช้ HTTPS เป็นปัจจัย ranking และเบราวเซอร์อย่าง Chrome จะแสดงคำเตือน "Not Secure" บนหน้า HTTP ทันที ส่งผลต่อความเชื่อมั่นของผู้ใช้โดยตรง

นอกจาก HTTPS แล้ว การจัดการ www vs non-www ก็สำคัญเท่ากัน เพราะ https://example.com และ https://www.example.com ถือเป็น URL คนละตัวในสายตาของ search engine หากปล่อยให้ทั้งสอง version เข้าถึงได้ อาจเกิดปัญหา duplicate content ที่ส่งผลเสียต่อ SEO

# บังคับ HTTPS ทุก request (ไม่จำกัด www หรือไม่)
RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

# บังคับ HTTPS + Redirect www → non-www (แนะนำ)
RewriteEngine On
RewriteCond %{HTTPS} off [OR]
RewriteCond %{HTTP_HOST} ^www\.(.+)$ [NC]
RewriteRule ^ https://%1%{REQUEST_URI} [R=301,L]

# หรือแยกเป็น 2 rule ชัดเจนกว่า
# Step 1: บังคับ HTTPS
RewriteCond %{HTTPS} off
RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

# Step 2: Redirect www → non-www
RewriteCond %{HTTP_HOST} ^www\.(.+)$ [NC]
RewriteRule ^ https://%1%{REQUEST_URI} [R=301,L]

# Redirect non-www → www (กรณีต้องการ www)
RewriteCond %{HTTP_HOST} !^www\. [NC]
RewriteRule ^ https://www.%{HTTP_HOST}%{REQUEST_URI} [R=301,L]

ถ้าใช้ Cloudflare หรือ reverse proxy อื่น ๆ ที่ terminate SSL ก่อนถึง server ตัวแปร %{HTTPS} อาจเป็น "off" เสมอแม้ผู้ใช้เข้าด้วย HTTPS ในกรณีนี้ให้ตรวจสอบ header X-Forwarded-Proto แทน:

# สำหรับเว็บที่อยู่หลัง Cloudflare หรือ Load Balancer
RewriteCond %{HTTP:X-Forwarded-Proto} !https
RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

หลังจากตั้งค่า HTTPS redirect แล้ว ควรเพิ่ม HSTS (HTTP Strict Transport Security) header เพื่อบอกเบราวเซอร์ว่าควร connect ด้วย HTTPS เสมอ แม้ user พิมพ์ HTTP เอง:

# เพิ่ม HSTS header (max-age = 1 ปี)
<IfModule mod_headers.c>
    Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains"
</IfModule>

ป้องกันไฟล์และโฟลเดอร์ด้วย .htaccess

การป้องกันความปลอดภัยผ่าน .htaccess ครอบคลุมหลายระดับ ตั้งแต่การป้องกัน directory ด้วย password, การห้าม direct access ไฟล์สำคัญ, ไปจนถึงการปิด directory listing ที่เปิดเผยโครงสร้างไฟล์ของเว็บไซต์

ป้องกัน directory ด้วย HTTP Basic Auth โดยต้องสร้างไฟล์ .htpasswd ก่อน โดยใช้คำสั่ง htpasswd -c /path/to/.htpasswd username บน server หรือใช้เครื่องมือ online generator:

# ป้องกัน directory ด้วย password
AuthType Basic
AuthName "Protected Area — กรุณาใส่รหัสผ่าน"
AuthUserFile /home/user/private/.htpasswd
Require valid-user

# อนุญาตเฉพาะ user บางคน (จาก .htpasswd)
Require user admin editor

ห้าม direct access ไฟล์สำคัญ เช่น ไฟล์ config, ไฟล์ backup หรือ log ที่ไม่ควรให้ public เข้าถึงได้:

# ห้ามเข้าถึงไฟล์ config และ backup
<FilesMatch "\.(env|sql|log|bak|config|ini)$">
    Require all denied
</FilesMatch>

# ห้าม access .htaccess และ .htpasswd ตัวเอง
<FilesMatch "^\.ht">
    Require all denied
</FilesMatch>

# ห้ามเข้าถึงไฟล์ PHP ใน uploads/
<Directory /var/www/html/uploads>
    <FilesMatch "\.php$">
        Require all denied
    </FilesMatch>
</Directory>

ปิด directory listing ป้องกันไม่ให้ Apache แสดงรายการไฟล์เมื่อไม่มีไฟล์ index:

# ปิด directory listing ทั้งเว็บไซต์
Options -Indexes

# ปิด directory listing เฉพาะ directory นี้
Options All -Indexes

# จำกัดสิทธิ์การเข้าถึงเฉพาะ IP (เช่น admin panel)
<Files "admin.php">
    Require ip 203.150.100.50
    Require ip 192.168.1.0/24
</Files>

การป้องกันระดับนี้ไม่ใช่ระบบรักษาความปลอดภัยที่สมบูรณ์แบบ ควรใช้ร่วมกับมาตรการอื่น เช่น ใช้รหัสผ่านที่แข็งแกร่ง, อัปเดต CMS และปลั๊กอินเป็นประจำ, และใช้ Web Application Firewall (WAF)

Caching และ Gzip compression เพื่อเพิ่มความเร็ว

การตั้งค่า browser caching และ Gzip compression ผ่าน .htaccess เป็นวิธีง่ายที่สุดในการเพิ่มความเร็วเว็บไซต์ โดยไม่ต้องแก้ไขโค้ดโปรแกรม ผลลัพธ์ที่ได้คือ PageSpeed score สูงขึ้น, Core Web Vitals ดีขึ้น, และประสบการณ์ผู้ใช้ที่ดีกว่าเดิม

Gzip/Deflate Compression บีบอัด HTML, CSS, JavaScript และ JSON ก่อนส่งให้ browser ช่วยลดขนาดไฟล์ได้ถึง 60-80% โดยเฉพาะไฟล์ text:

# เปิด Gzip Compression ด้วย mod_deflate
<IfModule mod_deflate.c>
    AddOutputFilterByType DEFLATE text/html
    AddOutputFilterByType DEFLATE text/css
    AddOutputFilterByType DEFLATE application/javascript
    AddOutputFilterByType DEFLATE application/json
    AddOutputFilterByType DEFLATE text/xml
    AddOutputFilterByType DEFLATE application/xml
    AddOutputFilterByType DEFLATE application/rss+xml
    AddOutputFilterByType DEFLATE image/svg+xml
    AddOutputFilterByType DEFLATE font/woff2

    # ข้าม browser เก่าที่มีปัญหา Gzip
    BrowserMatch ^Mozilla/4 gzip-only-text/html
    BrowserMatch ^Mozilla/4\.0[678] no-gzip
    BrowserMatch \bMSIE !no-gzip !gzip-only-text/html
</IfModule>

Browser Caching ด้วย mod_expires กำหนดให้ browser เก็บ static files ไว้ใน cache ช่วยลด HTTP request ในการเข้าชมครั้งถัดไป:

<IfModule mod_expires.c>
    ExpiresActive On

    # รูปภาพ — cache 1 ปี (ไม่ค่อยเปลี่ยน)
    ExpiresByType image/jpeg "access plus 1 year"
    ExpiresByType image/png  "access plus 1 year"
    ExpiresByType image/webp "access plus 1 year"
    ExpiresByType image/gif  "access plus 1 year"
    ExpiresByType image/svg+xml "access plus 1 year"
    ExpiresByType image/x-icon "access plus 1 year"

    # Fonts — cache 1 ปี
    ExpiresByType font/woff2 "access plus 1 year"
    ExpiresByType font/woff  "access plus 1 year"

    # CSS/JS — cache 1 เดือน (อัปเดตบ่อยขึ้น)
    ExpiresByType text/css "access plus 1 month"
    ExpiresByType application/javascript "access plus 1 month"

    # HTML — cache สั้น (เนื้อหาเปลี่ยนบ่อย)
    ExpiresByType text/html "access plus 1 hour"

    # default
    ExpiresDefault "access plus 1 week"
</IfModule>

# Cache-Control headers เพิ่มเติม
<IfModule mod_headers.c>
    <FilesMatch "\.(css|js|jpg|jpeg|png|gif|webp|ico|woff|woff2)$">
        Header set Cache-Control "max-age=2592000, public"
    </FilesMatch>
    <FilesMatch "\.html$">
        Header set Cache-Control "max-age=3600, public, must-revalidate"
    </FilesMatch>
</IfModule>

ควรระวังเรื่อง cache busting เมื่ออัปเดตไฟล์ CSS หรือ JS ถ้า cache นานเกินไป user จะยังเห็นเวอร์ชันเก่า วิธีแก้คือใส่ version string ต่อท้าย URL เช่น style.css?v=2.1 หรือใช้ filename hash เช่น style.abc123.css

Custom Error Pages 404 403 500

หน้า error ที่ดีช่วยรักษาประสบการณ์ผู้ใช้เมื่อเกิดปัญหา แทนที่จะเห็นหน้า error แบบ default ของ Apache ที่ดูแข็งและไม่มีข้อมูล ผู้ใช้ควรได้รับหน้าที่มีแบรนด์ของคุณ พร้อม navigation เพื่อกลับไปหน้าอื่น

HTTP error codes ที่พบบ่อยที่สุด ได้แก่ 404 (Not Found — URL ที่ร้องขอไม่มีอยู่), 403 (Forbidden — ไม่มีสิทธิ์เข้าถึง), 500 (Internal Server Error — error ฝั่ง server), และ 401 (Unauthorized — ต้อง login ก่อน)

# กำหนด Custom Error Pages
ErrorDocument 400 /errors/400.html
ErrorDocument 401 /errors/401.html
ErrorDocument 403 /errors/403.html
ErrorDocument 404 /errors/404.html
ErrorDocument 500 /errors/500.html
ErrorDocument 503 /errors/503.html

# หรือ redirect ไปยัง URL เต็ม
ErrorDocument 404 https://example.com/not-found.html

# Error page แบบ inline (เหมาะสำหรับ message สั้น ๆ)
ErrorDocument 403 "Access Denied — กรุณาติดต่อผู้ดูแลระบบ"

# Maintenance mode: redirect ทุกหน้าไปยัง maintenance page
# (ยกเว้น IP ของคุณเอง)
RewriteEngine On
RewriteCond %{REMOTE_ADDR} !^203\.150\.100\.50$
RewriteCond %{REQUEST_URI} !/maintenance.html$
RewriteRule ^(.*)$ /maintenance.html [R=302,L]

เมื่อสร้างหน้า 404 ควรใส่ elements เหล่านี้: navigation bar เพื่อกลับหน้าแรก, search box, หน้าที่นิยม 3-5 หน้า, ข้อความขอโทษและอธิบายว่าทำไมถึงเกิดขึ้น นอกจากนี้ควรตรวจสอบ 404 log เป็นประจำ เพราะอาจบ่งชี้ว่ามีลิงก์เสียในเว็บไซต์ที่ต้องแก้ไข

สำหรับหน้า 500 ควรออกแบบให้เรียบง่าย เพราะอาจเกิดขึ้นขณะ PHP หรือ database มีปัญหา หน้า 500 ไม่ควรพึ่งพา PHP หรือ database ใด ๆ ควรเป็น static HTML ล้วนเพื่อให้แสดงได้แม้ server มีปัญหา

Block IP Addresses และ Hotlinking

การ block IP ช่วยป้องกันการโจมตีแบบ brute force, spam bot, หรือ scraper ที่ดึงเนื้อหาเว็บไซต์ไปใช้โดยไม่ได้รับอนุญาต ส่วนการป้องกัน hotlinking ช่วยประหยัด bandwidth เมื่อเว็บไซต์อื่นนำรูปภาพของคุณไปแสดงโดยตรง (ทำให้ server ของคุณต้องรับ traffic โดยไม่ได้อะไรกลับมา)

Block IP ใน Apache 2.4 ขึ้นไป (ซึ่งเป็น version ที่ใช้กันอยู่ในปัจจุบัน):

# Block IP เดียว
Require not ip 192.168.1.100

# Block หลาย IP
<RequireAll>
    Require all granted
    Require not ip 192.168.1.100
    Require not ip 10.0.0.5
    Require not ip 203.0.113.25
</RequireAll>

# Block ทั้ง subnet /24 (256 IP)
Require not ip 192.168.1

# อนุญาตเฉพาะ IP ที่กำหนด (deny others)
Require ip 203.150.100.50
Require ip 192.168.0.0/16

# Block ด้วย mod_rewrite (ยืดหยุ่นกว่า — ทำงานกับ Apache เก่า)
RewriteEngine On
RewriteCond %{REMOTE_ADDR} ^192\.168\.1\.100$
RewriteRule ^ - [F,L]

ป้องกัน Hotlinking รูปภาพ ไม่ให้เว็บอื่นแสดงรูปจาก server ของคุณ:

# ป้องกัน Hotlinking รูปภาพทั้งหมด
RewriteEngine On
RewriteCond %{HTTP_REFERER} !^$
RewriteCond %{HTTP_REFERER} !^https?://(www\.)?yourdomain\.com [NC]
RewriteCond %{HTTP_REFERER} !^https?://yourdomain\.com [NC]
RewriteRule \.(jpg|jpeg|png|gif|webp|svg)$ /images/hotlink-forbidden.png [NC,L]

# หรือตอบกลับด้วย 403 แทน
RewriteCond %{HTTP_REFERER} !^$
RewriteCond %{HTTP_REFERER} !^https?://(www\.)?yourdomain\.com [NC]
RewriteRule \.(jpg|jpeg|png|gif|webp)$ - [F,NC,L]

# อนุญาตเฉพาะ domain ที่ไว้วางใจ
RewriteCond %{HTTP_REFERER} !^https?://(www\.)?partner\.com [NC]
RewriteRule \.(jpg|png|gif)$ /403.png [NC,L]

ควรระวังว่าการตั้ง Referer check นี้อาจ block การแสดงรูปในกรณีที่ผู้ใช้เปิดรูปโดยตรง (blank referer) หรือบางเบราวเซอร์ไม่ส่ง Referer header ด้วยเหตุผลด้าน privacy การ block แบบ strict เกินไปอาจทำให้รูปแสดงผลผิดพลาดบนเว็บไซต์ของตัวเองได้ในบางกรณี

ข้อควรระวังและวิธี debug .htaccess

ข้อผิดพลาดใน .htaccess ส่งผลให้เกิด error 500 (Internal Server Error) ทันที ซึ่งทำให้เว็บไซต์ไม่สามารถเข้าถึงได้เลย ดังนั้นการทดสอบและ debug จึงสำคัญมากก่อนการ deploy จริง

ข้อควรระวังที่พบบ่อย:

วิธี debug .htaccess:

# เปิด RewriteLog สำหรับ debug (Apache 2.2)
RewriteLog /tmp/rewrite.log
RewriteLogLevel 3

# Apache 2.4 ใช้ LogLevel แทน
LogLevel alert rewrite:trace3

# ทดสอบ syntax ก่อน deploy
# บน server: apachectl -t (ตรวจ httpd.conf)
# สำหรับ .htaccess ต้อง validate ด้วยมือ

ขั้นตอน debug ที่แนะนำ: ทดสอบใน staging environment ก่อนเสมอ, เพิ่ม rule ทีละบรรทัดและทดสอบ, ตรวจสอบ Apache error log (/var/log/apache2/error.log), ใช้ browser DevTools ดู HTTP redirect chain และ status codes, ใช้ online tool เช่น htaccess tester เพื่อ simulate rule

Performance tip: ทุกครั้งที่ Apache รับ request จะต้องอ่านไฟล์ .htaccess ในทุก directory ตลอด path หาก performance สำคัญมาก ควรย้าย rule ไปไว้ใน httpd.conf หรือ <VirtualHost> block แทน แล้วตั้ง AllowOverride None เพื่อลดการอ่านไฟล์ที่ไม่จำเป็น

แนะนำAsiaGB.com — Web Hosting สำหรับเว็บไซต์ที่ต้องการ .htaccess เต็มรูปแบบ รองรับ Apache พร้อม AllowOverride All ทุกแผน สตอเรจ SSD จัดการผ่าน DirectAdmin ทีม Support ภาษาไทย 24 ชั่วโมง uptime 99%

AsiaGB.com — Apache hosting with full .htaccess support, AllowOverride All, SSD storage, DirectAdmin control panel, 24h Thai support, 99% uptime.

เยี่ยมชม AsiaGB →

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

.htaccess ใช้ได้กับ Web Server อะไร?
.htaccess ใช้ได้กับ Apache Web Server เท่านั้น ไม่รองรับ Nginx หรือ IIS โดยตรง Nginx ใช้ server block ใน nginx.conf แทน หาก hosting ของคุณใช้ LiteSpeed (เช่น cPanel บาง host) ก็รองรับ .htaccess ได้เช่นกัน เนื่องจาก LiteSpeed รองรับ Apache-compatible directives
.htaccess ทำให้เว็บช้าลงไหม?
Apache ต้องอ่านไฟล์ .htaccess ทุก HTTP request ซึ่งอาจเพิ่ม overhead เล็กน้อย หากต้องการ performance สูงสุดควรย้าย rule ไปไว้ใน httpd.conf แล้วตั้ง AllowOverride None แต่บน shared hosting .htaccess คือทางเดียวที่เข้าถึงได้ ผลกระทบด้าน performance มักไม่มีนัยสำคัญสำหรับเว็บทั่วไป
.htaccess ไม่ทำงาน ต้องแก้อย่างไร?
ตรวจสอบว่า AllowOverride ใน httpd.conf ถูกตั้งเป็น All หรือ Options ตรวจว่า mod_rewrite เปิดอยู่ด้วย phpinfo() หรือ apache2ctl -M | grep rewrite ตรวจ syntax ของ rule ว่าถูกต้อง และดู Apache error log เพื่อหา error message เฉพาะเจาะจง
ควรวาง rule ใน .htaccess หรือ httpd.conf?
httpd.conf ให้ performance ดีกว่าเพราะ Apache อ่านครั้งเดียวตอน start และต้อง restart เมื่อแก้ไข แต่ .htaccess สะดวกกว่าสำหรับ shared hosting เพราะไม่ต้อง restart server และแก้ไขได้ทันที สำหรับ VPS หรือ dedicated server ที่เข้าถึง httpd.conf ได้ แนะนำให้ย้าย rule ไปไว้ใน httpd.conf เพื่อ performance ที่ดีกว่า