Guide Read Website Error Logs in aaPanel Free Edition (Nginx)

Guide Read Website Error Logs in aaPanel Free Edition (Nginx) - Printable Version

+- AdminsForum (https://adminsforum.com)
+-- Forum: Free & open-source control panels (https://adminsforum.com/Forum-free-open-source-control-panels)
+--- Forum: aaPanel (https://adminsforum.com/Forum-aapanel)
+---- Forum: aaPanel Guides & Tutorials (https://adminsforum.com/Forum-aapanel-guides-tutorials)
+----- Forum: aaPanel Websites & Web Servers Guides (https://adminsforum.com/Forum-aapanel-websites-web-servers-guides)
+----- Thread: Guide Read Website Error Logs in aaPanel Free Edition (Nginx) (/Thread-guide-read-website-error-logs-in-aapanel-free-edition-nginx)

Read Website Error Logs in aaPanel Free Edition (Nginx) - DEV - 10-11-2026

To diagnose a website error in aaPanel Free Edition, reproduce it once, note the time and URL, then match that request in the access and error logs. The status code tells you what the visitor received; the error log can explain what failed.

Tested by AdminsForum: 11 October 2026, Ubuntu 22.04.5, aaPanel Free Edition 8.0.6 and Nginx 1.30.5. We requested a deliberately missing page on adminslab.com, confirmed HTTP 404, and found matching entries in both logs. No website files or service settings were changed for this test.

1. Reproduce the problem and record the time
Open the affected URL once. Write down its path, the approximate time, and the message shown. Use a harmless missing path on your own test site if you want to practise:

Code:

https://your-domain.example/af-log-tutorial-missing-page

Our test displayed the 404 page shown below. This is an intentional missing-page result, not an installation failure.

AdminsForum lab screenshot — deliberate 404 response
[Image: aapanel-log-404-tested-20261011.png?v=1]

[Image: aapanel-log-404-tested-20261011.png?v=1]

2. Locate your site's log files
Sign in to your own aaPanel and open its File Manager. Navigate to:

Code:

/www/wwwlogs/

Find the files for the website you created. On our lab they are:

Code:

/www/wwwlogs/adminslab.com.log
/www/wwwlogs/adminslab.com.error.log

The first is the access log; the second is the Nginx website error log. Open them for viewing. Do not clear, delete, or save edits to the logs while diagnosing the incident. File names can differ: confirm your site's access_log and error_log paths in its Nginx configuration if these names are absent.

If you use SSH instead, read recent entries with these commands, replacing the domain with your own site's actual log name:

Code:

sudo tail -n 50 /www/wwwlogs/your-domain.example.log
sudo tail -n 50 /www/wwwlogs/your-domain.example.error.log

These commands read files; they do not restart Nginx or alter your website.

3. Match the request in the access log
Search for the exact path, rather than assuming the last line belongs to you:

Code:

sudo grep -F 'af-log-tutorial-missing-page' /www/wwwlogs/your-domain.example.log | tail -n 5

Our actual test entry, with the client address redacted, was:

Code:

[client IP] - - [11/Oct/2026:06:27:04 +0000] "GET /af-log-tutorial-missing-page HTTP/2.0" 404 58296 "-" "curl/7.81.0"

Read it in order: request time, GET path, protocol, response status, response size, referrer and client software. The 404 after the quoted request is the response code. Here +0000 means UTC; convert your browser's local time before comparing. A browser request may have a different user-agent from this SSH test.

4. Read the matching error entry
Search the same path in the error log:

Code:

sudo grep -F 'af-log-tutorial-missing-page' /www/wwwlogs/your-domain.example.error.log | tail -n 5

The important part of our matching entry was:

Code:

open() "/www/wwwroot/adminslab.com/af-log-tutorial-missing-page" failed (2: No such file or directory)

This confirms Nginx tried to read a path that did not exist. If it should be a real file, check the upload location and spelling, including letter case. If it should be a WordPress route, inspect the site's rewrite rules instead of creating an empty file to hide the error.

5. Choose the next check from the evidence

404 / file not found: Check the document root, requested path, file name and application routing.
403 / permission denied: Check the exact path's ownership, permissions and access rules. Do not apply chmod 777 as a general fix.
502 / upstream connection failure: Check the selected PHP version, its PHP-FPM service and the configured socket or port. An upstream timeout has a different investigation from a refused connection.
500: Check application and PHP logs too. A web-server access entry alone usually does not identify the application exception.

You may see requests for .env, .git or other paths you never opened. These can be automated scans. Match the URL and time of your actual problem before changing anything. A missing-file scanner entry alone does not establish that your site was compromised.

6. Verify and ask for help
After fixing the identified cause, reload the affected page and check its new status. Keep the original error evidence; it helps confirm what changed. When asking for support, include the panel version, web server, selected PHP version, affected path, timestamp/timezone and a few relevant redacted lines. Remove IP addresses, session tokens, private entrance URLs and query strings containing secrets.

Continue with:

Technical references: Nginx access logging and Nginx error logging. Apache and OpenLiteSpeed log locations and formats are outside this Nginx walkthrough.