403 Forbidden means NGINX understood the request but denied access to the resource. The issue may be due to missing index file, folder execution permission, ownership, allow/deny rule, SELinux, symlink policy, or security layer.
2026/07/17 03:31:08 [error] 2261#2261: *731 directory index of "/var/www/example/" is forbidden
2026/07/17 03:31:12 [error] 2261#2261: *734 open() "/var/www/example/index.php" failed (13: Permission denied)
403 is different from 404, which means file not found. NGINX may see the source or directory but configuration or operating system access request is blocked.
If the directory request does not find index.php or index.html and autoindex is off, NGINX writes 'directory index ... is forbidden'. In this case, instead of increasing permissions, the document root and index directive should be verified.
The file having 644 and the folder having 755 is not enough. The NGINX worker user must have execution permission on all parent folders up to the document root.
The allow and deny rules are evaluated in sequence. An inherited deny from the upper http/server block or a wrong IP network can lead to 403 being displayed for specific visitors.
SELinux context can block access even if Unix permissions appear correct on RHEL-based systems. The AVC log should be reviewed before the security layer is closed.
Using 777 for 403 solution is not a fix but a security vulnerability; namei, stat, NGINX worker, and security logs should prove the access chain.
Search for the phrase you see in the email, browser, or SSH log. Each card includes meaning, probable cause, and safe initial action.
Meaning: No suitable index file in directory or directory listing is disabled.
Possible cause: Incorrect root, missing index or index directive.
Meaning: NGINX cannot open the file at the operating system level.
Possible cause: File/folder permissions, ownership, ACL or SELinux.
Meaning: NGINX allow/deny or similar access rule blocked the request.
Possible cause: Incorrect IP network, include file, or inherited from upper block.
Meaning: Symlink policy or target path access was denied.
Possible cause: disable_symlinks, permission or ownership mismatch.
Meaning: The general browser message is not showing the root cause.
Possible cause: Index, permission, access rule or security layer.
Meaning: The server configuration rejected the client.
Possible cause: IP rule, location deny or Plesk extra directive.
Meaning: Kernel security policy blocked NGINX access.
Possible cause: Incorrect context or required boolean closed.
Meaning: FastCGI target is pointing to the wrong script path.
Possible cause: root/alias and SCRIPT_FILENAME incompatibility.
No records matching this expression were found.
Commands are for root access. Collect only status and logs first; Do not change the permanent setting without seeing the reason.
namei -l /var/www/example/index.php
stat /var/www/example /var/www/example/index.php
getfacl -p /var/www/example 2>/dev/null
Displays the entire access chain including parent folders.
ps -eo user,group,cmd | grep '[n]ginx: worker'
grep -n '^user' /etc/nginx/nginx.conf
Determines the actual user who needs access to the files.
nginx -T | grep -nE 'server_name|root |alias |index |allow |deny |disable_symlinks'
Displays active virtual host and access directives.
getenforce
ls -Zd /var/www/example
ausearch -m AVC -ts recent | tail -n 50
Verifies SELinux restriction outside of Unix permissions.
tail -n 150 /var/log/nginx/error.log
curl -skI https://example.com/
Tests the request and log line at the same time.
nginx -t && systemctl reload nginx
If configuration is successful, it will run uninterrupted.
Although the root cause of the NGINX error is the same, package paths, service names, security layers and virtual host management vary depending on the Linux distribution or Plesk infrastructure used.
Systemd, package path, and journald controls for NGINX 403 Forbidden.
namei -l /var/www/example/index.php
nginx -T | grep -nE 'root |index |allow |deny '
tail -n 100 /var/log/nginx/error.logSELinux, PHP-FPM pool, and RHEL-based service controls for NGINX 403 Forbidden.
namei -l /var/www/example/index.php
getenforce
ausearch -m AVC -ts recent | tail -n 30Plesk-generated NGINX virtual host files in nginx 403 forbidden control.
tail -n 100 /var/www/vhosts/system/example.com/logs/proxy_error_log
plesk repair web example.com -n
nginx -tFirst, determine why NGINX is rejecting it; test the index, permissions, access rules, and security layer separately.
Determine if the error is for everyone, or only for a specific IP or domain.
curl -skI https://example.com/korumali/Directory index, permission denied or access forbidden if found.
tail -n 100 /var/log/nginx/error.logCheck that the active server block is looking at the real file path.
nginx -T | grep -nE 'server_name|root |index 'Execute permission for NGINX worker must be present in all parent folders.
namei -l /var/www/example/index.phpSeparate allow/deny, ACL, SELinux and WAF logs.
nginx -T | grep -nE 'allow |deny '; ausearch -m AVC -ts recent | tailMake changes only to the faulty path/rule and check the new 403 record.
nginx -t && systemctl reload nginx
curl -skI https://example.com/korumali/Add the correct index file or make a conscious autoindex decision.
ls -la /var/www/example; nginx -T | grep -n 'index 'Check allow/deny, WAF and fail2ban logs.
nginx -T | grep -nE 'allow |deny 'Examine the real target's permissions and disable_symlinks directive.
readlink -f /var/www/example/current; namei -l /var/www/example/currentSELinux AVC logs and file context should be checked.
ls -Zd /var/www/example; ausearch -m AVC -ts recent | tailSeparate Uploads ownership, hotlink/WAF rule, and location matching.
curl -skI https://example.com/wp-content/uploads/test.jpgReview the Additional nginx directives content on the Domains screen.
plesk repair web example.com -nMissing index file, incorrect root, file permissions, ownership, allow/deny rules, SELinux or security layer are the most common causes.
First, verify that the correct document root contains index.php or index.html and that the index directive contains this file.
No. 777 security vulnerability creates and hides the real owner/access chain issue. name, stat, and worker user control should be performed.
SELinux, ACL, allow/deny, WAF, symlink policy, or incorrect document root Unix permissions may still produce a 403 error even if correct.
Check the user directive in nginx.conf and the user of the running worker process with the ps command.
Uploads permissions, security plugin, WAF, hotlink rule, deny location or incorrect PHP script path.
First, check the domain proxy_error_log and additional NGINX directives; if necessary, the plesk repair web command should be used for the relevant domain.
By analyzing cPanel, WHM, CloudLinux, LiteSpeed, MariaDB, Exim and security layers together, we fix the root cause of the failure instead of just removing the service.