Chyba 403 Forbidden: příčiny a jak ji opravit

Chyba 403 Forbidden znamená, že server požadavek přijal a zdroj našel, ale přístup k němu záměrně odmítá. Obvyklé příčiny jsou oprávnění souborů nebo adresářů, pravidlo deny v .htaccess nebo v konfiguraci nginx, chybějící soubor index, blokace IP, ochrana proti hotlinkingu, WAF nebo bezpečnostní plugin WordPressu. Příčinu téměř vždy odhalíte podle dvou vodítek: jakou stránku server vrátil a co ve stejné sekundě zapsal chybový log.

Kdo vrátil 403: poznáte to podle stránky

Nejdřív zjistěte, která vrstva přístup odmítla. Na testovacím serveru každá zobrazovala vlastní stránku:

• Apache: nadpis „Forbidden“ a řádek „You don’t have permission to access this resource.“ Zkontrolujte .htaccess a oprávnění souborů.
• nginx: vycentrované „403 Forbidden“ a dole verze nginx. Zasáhlo pravidlo nginx: deny, ochrana proti hotlinkingu, filtr požadavků.
• Jen „Access denied.“ bez jakéhokoli formátování: PHP-FPM nedokázal otevřít PHP skript.
• Stránka ve stylu WordPressu s hlášením, že jste zablokováni: přístup uzavřel plugin.
• Stránka CDN s ID požadavku: blokuje vás síť pro doručování obsahu, požadavek se k vašemu serveru vůbec nedostal.

Hlavičce Server nevěřte. Za nginx ukazovala Server: nginx, i když 403 vygeneroval Apache. Stavový kód a stránku bez mezipaměti prohlížeče zobrazíte takto:

curl -sS -I https://example.com/path
curl -sS https://example.com/path | head -20

Pokud nefunguje celý web, a ne jen pár stránek, začněte naším návodem, jak diagnostikovat problém krok za krokem.

Tabulka: co vidíte, kde hledat, jak opravit

Co jsme na testovacím serveru rozbili a co jsme viděli

Oprávnění a vlastník souborů

Na hostingu s panelem běží PHP obvykle pod vlastníkem účtu, zatímco nginx a Apache pod jiným systémovým uživatelem. Proto se stejný chmod chová různě. Režim 600 na souboru index.php, který patří vlastníkovi účtu, nic nerozbil: PHP četlo soubor jako vlastník a stránka vracela 200. Stejný režim 600 na obrázku dal 403, protože statické soubory čte webový server:

apache: AH00132: file permissions deny server access: .../uploads/2026/11/photo.png
nginx:  open() ".../uploads/2026/11/photo.png" failed (13: Permission denied)

Režim 700 na adresáři zamkne vše uvnitř. Po chmod 700 wp-admin se přihlašovací stránka stále otevřela, ale administrace a její styly vracely 403 a Apache zapsal AH00529 ... ensure it is readable and that '.../wp-admin/' is executable. Režim 750 na kořenovém adresáři webu shodil celý web.

Dvě překvapení. Zaprvé: se samotným nginx a obvyklým try_files nečitelný obrázek nevyvolal 403: nginx předal požadavek WordPressu, který odpověděl přesměrováním. Zadruhé: když byl PHP soubor pro vlastníka webu nečitelný, web dál běžel z OPcache po celých 15 sekund, co jsme ho sledovali, a 403 „Access denied.“ se objevilo až po restartu PHP. Špatný chmod se tak může projevit až o několik hodin později, třeba po nočním restartu.

Řešení: adresáře 755, soubory 644, wp-config.php může mít 600 nebo 640, vlastníkem je váš uživatel. Nikdy nepoužívejte 777.

find public_html -type d -exec chmod 755 {} +
find public_html -type f -exec chmod 644 {} +

Chybí soubor index nebo je web ve špatné složce

Když v kořenovém adresáři není index.php ani index.html a výpis adresářů je vypnutý, Apache vrátí 403 a zapíše do logu:

AH01276: Cannot serve directory /srv/cw1/www/: No matching DirectoryIndex (index.php,index.html) found, and server-generated directory index forbidden by Options directive

nginx je stručnější: directory index of ".../www/" is forbidden. Stejný záznam jsme dostali, když se soubory webu omylem nahrály do podsložky public_html/site/: úvodní stránka vracela 403, zatímco /site/ se otevřela. Pokud kořenová složka domény ukazuje na adresář, ke kterému webový server nemá přístup, v logu je AH01630 client denied by server configuration. Ověřte, ve které složce máte soubory a kterou složku panel pro doménu používá.

Nezapínejte Options +Indexes jen proto, aby 403 zmizela: na testovacím serveru to odhalilo výpis souborů včetně .htaccess.

Pravidla deny v .htaccess

Require all denied vrátilo 403 a AH01630: client denied by server configuration s přesnou cestou k souboru. Stará syntaxe Order deny,allow a Deny from all fungovala stejně (AH01797), ale jen proto, že byl načtený modul mod_access_compat. Bez něj vracel tentýž soubor chybu 500, ne 403, s hlášením Invalid command 'Order'. Dokumentace Apache 2.4 označuje tyto direktivy za zastaralé, přejděte proto na Require.

Bezpečnostní pluginy často dávají do složky uploads soubor .htaccess, který blokuje spouštění PHP. Správná verze blokuje jen PHP a obrázky dál fungují:

<Files *.php>
Require all denied
</Files>

Pokud je v něm jen Require all denied, zmizí z webu všechny obrázky. Nejrychlejší test: dočasně přejmenujte .htaccess v daném adresáři.

Pravidla nginx a blokace IP

allow a deny v nginx vracejí stránku nginx a jasný řádek v logu:

access forbidden by rule, client: 127.0.0.4, server: bench.test, request: "GET /wp-admin/install.php HTTP/1.1"

Nejzajímavější byla pravidla IP v .htaccess. Když nginx stojí před Apache a nepředává skutečnou adresu návštěvníka, Apache vidí adresu samotného nginx. Na testovacím serveru Require not ip pro „špatnou“ adresu nic neblokovalo, zatímco Require ip s adresou správce zamklo venku i správce. Přístupový log Apache ukazoval u každého požadavku 127.0.0.1. Po nastavení mod_remoteip začala obě pravidla fungovat, jak měla. Než začnete psát pravidla IP, ověřte v přístupovém logu, jakou adresu server skutečně vidí.

Ochrana proti hotlinkingu

Pravidlo založené na hlavičce Referer brání cizím webům vkládat vaše obrázky. Na testovacím serveru nginx s valid_referers none blocked server_names pouštěl přímé požadavky i požadavky z vlastního webu a cizímu webu vracel 403. Jenže 403 dostávala i verze webu s www, protože chyběla v server_name. Varianta v .htaccess se chovala stejně a ani Apache, ani nginx nezapsaly do chybového logu jediný řádek: tento typ 403 je vidět jen v přístupovém logu. Po přechodu na novou doménu nebo přidání www aktualizujte seznam povolených.

WAF a ModSecurity: blokace podle User-Agent nebo parametrů

V nginx jsme emulovali typické pravidlo firewallu: blokovat prázdný User-Agent, známé skenery a požadavky s union select nebo značkou script v parametrech. Běžný prohlížeč dostal 200; User-Agent python-requests/2.31 a vyhledávání ?s=union+select+price dostaly 403. Tyto požadavky se nikdy nedostaly k Apache ani k WordPressu, chybový log zůstal prázdný a přístupový log ukazoval jen kód a User-Agent. Skutečný ModSecurity zapisuje i ID pravidla a právě toto ID pošlete svému poskytovateli hostingu. Ochranu úplně nevypínejte; stačí výjimka pro jedno pravidlo.

Bezpečnostní plugin WordPressu

Náš testovací plugin zablokuje IP kódem 403 po třech neúspěšných přihlášeních. Po třech špatných heslech web zobrazil stránku „Access blocked“ ve stylu WordPressu, zatímco z jiné adresy vše fungovalo. V logech webového serveru nebylo nic, jen 403 v přístupovém logu. Když Apache neviděl skutečné adresy, plugin zablokoval celý web všem návštěvníkům, protože každý požadavek zdánlivě přicházel z adresy nginx.

Řešení: přejmenujte složku pluginu ve wp-content/plugins přes FTP nebo správce souborů v panelu. Na testovacím serveru se web okamžitě vrátil, WordPress plugin prostě přestal načítat. Pak vraťte původní název, přihlaste se a přidejte svou adresu na seznam povolených.

Kde najít logy a kdy kontaktovat podporu

V ovládacím panelu má každá doména obvykle přístup ke svému přístupovému a chybovému logu. Hledejte řádek se stejným časem a cestou jako váš požadavek. Pokud je 403 v přístupovém logu, ale ne v chybovém, může za to pravidlo, které odpovídá potichu: ochrana proti hotlinkingu, filtr WAF, plugin. Pokud požadavek není ani v přístupovém logu, k serveru se vůbec nedostal: zkontrolujte CDN nebo externí firewall.

Na podporu se obraťte, když vás blokuje pravidlo na úrovni serveru: ModSecurity, firewall nebo nastavení webového serveru, které nemůžete změnit. Uveďte URL, přesný čas, svou IP a řádek z logu. Jiné stavové kódy mají úplně jiné příčiny: chyba 500 obvykle pochází z PHP nebo ze syntaxe .htaccess, jako v návodu ke kritické chybě WordPressu; 502 Bad Gateway znamená, že backend neodpovídá; chyba 503 Service Unavailable ukazuje na přetížení nebo údržbu; a 504 Gateway Timeout znamená, že backend odpověděl příliš pozdě. Všechny tarify sdíleného hostingu RichHost zahrnují vlastní ovládací panel s asistentem AI.

Časté otázky

Jaký je rozdíl mezi 403, 404 a 401?

404 znamená, že zdroj nebyl nalezen. 401 žádá ověření: po přihlášení se přístup může otevřít. 403 znamená, že server požadavku porozuměl, ale odmítá ho, a nový pokus se stejnými přihlašovacími údaji nic nezmění.

Proč 403 vidím jen já, když se mi web na telefonu otevře?

Nejspíš je zablokovaná vaše IP: bezpečnostním pluginem po neúspěšných přihlášeních, pravidlem v .htaccess nebo firewallem. Vyzkoušejte to přes mobilní data a vyhledejte svou adresu v přístupovém logu.

Můžu nastavit 777, aby chyba zmizela?

Ne. Stačí 755 pro adresáře a 644 pro soubory. 777 umožní zápis do souborů komukoli a špatného vlastníka neopraví.

Chyba se objevila sama, nic jsem neměnil. Co to je?

Oprávnění se mohla změnit dříve a projevit se až po restartu PHP, jako na našem testovacím serveru. Další časté příčiny: aktualizace bezpečnostního pluginu, nové pravidlo WAF u vašeho poskytovatele hostingu nebo blokace IP po několika neúspěšných přihlášeních.