Όταν το .htaccess ρίχνει ολόκληρο το site

Το αρχείο .htaccess είναι ένα από τα πιο ισχυρά εργαλεία που έχεις στη διάθεσή σου σε ένα shared hosting περιβάλλον. Ελέγχει redirects, rewrites, ασφάλεια, cache headers — σχεδόν τα πάντα που αφορούν τη συμπεριφορά του web server για το site σου. Και ακριβώς επειδή είναι τόσο ισχυρό, ένα μικρό λάθος μπορεί να ρίξει ολόκληρο το site ή να ανοίξει τρύπες ασφαλείας.

Παρακάτω είναι τα τρία πιο συχνά λάθη που βλέπουμε σε .htaccess αρχεία — και πώς να τα διορθώσεις.

1. Loops στα redirects που οδηγούν σε Too Many Redirects

Ένα από τα πιο συνηθισμένα λάθη είναι να δημιουργήσεις ακούσια έναν loop redirect — δηλαδή μια κατάσταση όπου το URL ανακατευθύνεται στον εαυτό του ή σε άλλο URL που ανακατευθύνεται πίσω.

Παράδειγμα προβληματικού κώδικα:

RewriteEngine On
RewriteRule ^(.*)$ https://example.com/$1 [R=301,L]

Αν αυτό το έχεις σε ένα site που ήδη τρέχει στο https://example.com, δημιουργεί loop: κάθε αίτημα ανακατευθύνεται στον εαυτό του, και ο browser σταματά μετά από επανειλημμένες ανακατευθύνσεις με σφάλμα «Too many redirects» ή ERR_TOO_MANY_REDIRECTS.

Η λύση είναι να προσθέσεις συνθήκες που ελέγχουν αν το αίτημα ΗΔΗ έρχεται από το σωστό domain και πρωτόκολλο:

RewriteEngine On

RewriteCond %{HTTPS} !=on [OR]
RewriteCond %{HTTP_HOST} !^example\.com$ [NC]
RewriteRule ^ https://example.com%{REQUEST_URI} [R=301,L]

Τώρα το redirect θα εκτελεστεί μόνο αν το αίτημα ΔΕΝ είναι ήδη HTTPS ή αν το hostname ΔΕΝ είναι example.com. Έτσι διορθώνεις και HTTP → HTTPS και λάθος hostname με έναν κανόνα.

Tip: Αν το site σου έπεσε μετά από αλλαγή στο .htaccess, μπες στο cPanel → File Manager, βρες το αρχείο (συνήθως στο public_html), κάνε δεξί κλικ και επίλεξε Edit, και σχολίασε (βάλε # μπροστά) τις γραμμές που πρόσθεσες. Αν το site ξαναδουλέψει, το πρόβλημα είναι εκεί.

2. Λανθασμένη σειρά RewriteRule που ακυρώνει κανόνες

Το .htaccess εκτελείται από πάνω προς τα κάτω. Η σειρά των κανόνων έχει σημασία — και πολλές φορές ένας κανόνας που μπαίνει λάθος θέση ακυρώνει έναν άλλον που χρειάζεσαι.

Παράδειγμα: έχεις έναν κανόνα που στέλνει όλα τα URLs στο index.php, αλλά θέλεις να εξαιρέσεις το /api directory. Αν βάλεις την εξαίρεση ΜΕΤΑ τον γενικό κανόνα, δεν θα εκτελεστεί ποτέ:

RewriteEngine On
RewriteRule ^(.*)$ index.php [L]
RewriteRule ^api/(.*)$ api/handler.php [L]

Εδώ η δεύτερη γραμμή δεν θα τρέξει ποτέ, επειδή η πρώτη έχει το flag [L] (Last) και σταματά την επεξεργασία. Στο LiteSpeed, το [L] σταματά ουσιαστικά την περαιτέρω επεξεργασία των rewrite rules, με συμπεριφορά κοντά στο [END] του Apache 2.4 — άρα η σειρά των rules έχει ιδιαίτερη σημασία.

Η σωστή σειρά είναι να βάλεις τις εξαιρέσεις ΠΡΙΝ τους γενικούς κανόνες:

RewriteEngine On
RewriteRule ^api/(.*)$ api/handler.php [L]
RewriteRule ^(.*)$ index.php [L]

Ή καλύτερα, χρησιμοποίησε RewriteCond για να εξαιρέσεις ρητά το /api:

RewriteEngine On
RewriteCond %{REQUEST_URI} !^/api/
RewriteRule ^(.*)$ index.php [L]

Τώρα το RewriteRule θα εκτελεστεί μόνο αν το URI ΔΕΝ ξεκινά με /api/.

Tip: Αν έχεις πολλούς κανόνες rewrite, βάλε σχόλια (# Redirect old URLs, # WordPress permalinks) για να ξέρεις τι κάνει ο καθένας. Σε έξι μήνες δεν θα θυμάσαι γιατί τον έβαλες.

3. Χρήση παλιάς σύνταξης Order / Allow / Deny

Πολλοί κανόνες που βρίσκεις online είναι γραμμένοι για Apache 2.2 — μια έκδοση που χρησιμοποιούσε την παλιά σύνταξη order allow,deny. Το LiteSpeed υποστηρίζει τόσο την παλιά σύνταξη Order / Allow / Deny όσο και τη νεότερη σύνταξη Require. Για νέους κανόνες προτιμάμε τη σύνταξη Require, επειδή είναι πιο σύγχρονη, πιο ευανάγνωστη και συμβαδίζει με το Apache 2.4.

Παλιά σύνταξη (Apache 2.2):

<Files .htaccess>
order allow,deny
deny from all
</Files>

Σύγχρονη σύνταξη (Apache 2.4 / LiteSpeed):

<Files .htaccess>
Require all denied
</Files>

Η διαφορά δεν είναι μόνο αισθητική. Η νέα σύνταξη είναι πιο ρητή, πιο ευανάγνωστη και αποτελεί την προτεινόμενη επιλογή για νέους κανόνες.

Αν αντιγράφεις κανόνες από παλιά tutorials ή από το Stack Overflow, έλεγξε αν χρησιμοποιούν order και allow/deny. Αν ναι, ξαναγράψε τους με Require:

• allow from all → Require all granted
• deny from all → Require all denied
• allow from 192.168.1.1 → Require ip 192.168.1.1

Πώς να ελέγξεις αν το .htaccess σου είναι σωστό

Δεν υπάρχει built-in εργαλείο στο cPanel που να ελέγχει το .htaccess πριν το αποθηκεύσεις. Η μόνη σίγουρη μέθοδος είναι:

1. Κάνε backup το τρέχον .htaccess (κατέβασέ το ή αντίγραψε το περιεχόμενο σε ένα αρχείο .htaccess.backup).
2. Κάνε την αλλαγή.
3. Δοκίμασε το site αμέσως — ανοίγει; Τα redirects δουλεύουν; Δοκίμασε και σε incognito mode για να αποφύγεις cache του browser.
4. Αν κάτι πήγε στραβά, επανάφερε το backup αμέσως.

Αν το site έπεσε και δεν μπορείς να φορτώσεις ούτε το cPanel File Manager, μπορείς να συνδεθείς μέσω FTP ή SSH και να διαγράψεις ή να μετονομάσεις το .htaccess. Το site μπορεί να αρχίσει να αποκρίνεται ξανά χωρίς το .htaccess, αλλά ενδέχεται να μη λειτουργούν permalinks, redirects, κανόνες ασφαλείας, cache ή άλλες ρυθμίσεις. Για WordPress ειδικά, χωρίς .htaccess μπορεί η αρχική να ανοίγει αλλά τα pretty permalinks να δίνουν 404.

Συμπέρασμα

Το .htaccess είναι ένα αρχείο με τεράστια δύναμη — και τεράστια ευθύνη. Τα loops στα redirects και η λάθος σειρά κανόνων rewrite μπορούν να προκαλέσουν σοβαρά προβλήματα στη λειτουργία ενός site, ενώ η χρήση παλιάς σύνταξης κάνει το .htaccess δυσκολότερο στη συντήρηση και λιγότερο συμβατό με τις σύγχρονες πρακτικές. Κάνε πάντα backup πριν αλλάξεις κάτι, δοκίμασε αμέσως, και χρησιμοποίησε τη σύγχρονη σύνταξη Require για ασφάλεια.

Αν χρειαστείς βοήθεια με κάποιον κανόνα που δεν δουλεύει όπως περιμένεις, μπορείς να ζητήσεις βοήθεια από την υποστήριξη του παρόχου σου — το .htaccess debugging είναι συχνό αίτημα.