A 413 “Request Entity Too Large” response can come from a request-size limit before PHP handles an upload. Identify the layer returning it, check the matching log and change the smallest relevant limit. Increasing PHP's upload setting alone cannot fix a request rejected by Nginx.
Tested: Ubuntu 22.04.5 and the aaPanel lab's installed Nginx 1.30.5 binary. We ran a separate temporary Nginx instance listening only on 127.0.0.1, with its own configuration, PID and logs. A 2KiB request failed under a 1KiB limit and reached a dummy 200 handler under a 4KiB limit. We shut down the test instance afterwards. The normal website configuration and PHP settings were not changed.
1. Record the failed operation
Note the hostname/path, time/timezone, method, approximate file size, total request size and HTTP status. Find out whether a small upload works and a larger one fails. A multipart request contains framing and other fields in addition to the file bytes.
Check the browser's failed network request and the response. The wording may vary by Nginx version or another proxy. A CDN, reverse proxy, application or upload service can impose a separate limit; a response logo alone is not proof of the failing layer.
Do not repeatedly submit production imports or other actions that might create duplicate records. Use a controlled test workflow and harmless input.
2. Match the Nginx access and error logs
In the tested aaPanel interface, open Website → PHP Project → the site's Log button → Access log / Error log. Confirm the hostname and source path. Read the website-log guide for detailed searching and time matching.
Our isolated test access log recorded POST /request-size-check with status 413. Its matching error said:
Code:
client intended to send too large body: 2048 bytes
This supported a Nginx request-size diagnosis. It was not evidence of a PHP memory error, missing extension or failed database connection. If your website has no matching request, investigate the correct host/log and any earlier proxy layer before editing PHP.
3. Understand the tiny lab comparison
We sent the same 2,048-byte raw request body in both phases. With the relevant location set to:
Code:
client_max_body_size 1k;
Nginx returned 413. We changed only that test limit to:
Code:
client_max_body_size 4k;
After validation and a reload of the isolated instance, the same request received 200 and the dummy response text. The access log recorded both outcomes.
AdminsForum formatted transcript of the original experiment, not a terminal screenshot.
The handler returned a fixed message. This demonstrates the Nginx size gate; it does not prove PHP parsed multipart data, an application validated a file or anything was stored successfully. The endpoint was private, no public firewall port was opened and the normal website remained available.
4. Inspect the effective site configuration
For a real aaPanel incident, locate the affected website under Website → PHP Project and inspect its Conf/site configuration. Labels vary by release. Back up the relevant file before changing it and confirm which server/location handles the failing URL.
The Nginx directive can appear in http, server or location context. Check inherited settings and a more specific location rather than assuming a global value controls every route. Avoid adding duplicate directives in the same context or replacing an existing PHP handler with an incomplete example location.
An administrator can inspect the effective configuration privately with the installed binary:
Code:
/www/server/nginx/sbin/nginx -T
The output can contain private configuration details. Do not upload the entire dump to a public thread.
5. Choose a finite limit for the actual workflow
An illustrative site-level value is:
Code:
client_max_body_size 80m;
This is an example, not a value applied to the existing lab website or a universal recommendation. Place a chosen limit in the appropriate existing context and consider legitimate request size, concurrent uploads, temporary storage and application policy. Setting the Nginx value to zero disables its body-size check; it was not needed for our test.
Keep limits purposeful instead of making every upload unlimited. A narrow policy can be appropriate for a particular route, but it must preserve the route's existing processing/authentication configuration.
If a CDN or another reverse proxy rejects the request earlier, an origin-only change cannot remove that layer's limit. Review the actual service's documented current limits and supported workflow rather than weakening unrelated security controls.
6. Align PHP and application limits separately
When the request reaches PHP, check the site's selected PHP version and its active FPM settings. Relevant settings include upload_max_filesize for an uploaded file and post_max_size for the total POST data. Allow for request overhead and multiple files according to the intended application behavior.
Exceeding PHP's POST limit can leave POST/file data empty, so the application's error may differ from a Nginx 413. Verify the effective serving runtime; a CLI setting may not describe the website's PHP-FPM pool.
Follow Change PHP Upload and Memory Limits and the tested WordPress 64MB upload guide for those existing workflows. Application/plugin limits, validation and available temporary storage still matter. We did not change PHP limits in this experiment.
7. Validate and verify a real repair
Before reloading the affected site configuration on a normal aaPanel-managed Nginx installation:
Code:
/www/server/nginx/sbin/nginx -t
Use the panel's supported reload control only after validation succeeds. Our experiment reloaded only its separately configured test process, so the existing website configuration was not involved.
Test a small permitted upload and the intended larger upload through the real application, inspect the response/content and confirm the expected file or record was created. Check fresh logs and a normal page. Do not treat a dummy HTTP 200 as proof that a production upload completed.
Preserve a rollback copy. If a change breaks another route or causes resource pressure, restore the previous configuration, validate and repeat the relevant health checks.
8. Cleanup and test limits
The temporary listener was stopped, its PID file was removed by shutdown and a connection check confirmed its port was closed. The main Nginx configuration hash was unchanged and the normal website health check returned 200.
We retained the private experiment configuration and result logs as documentation. No real uploaded user file, production upload cap, PHP pool or database was modified. The tiny request was chosen to demonstrate the mechanism with bounded work rather than sending large files at a busy server.
A 403 Forbidden response means the request was denied, but it does not identify the rule or permission responsible. Read the matching error before changing file ownership, enabling directory listings or disabling security controls.
Tested: aaPanel Free 8.0.7, Ubuntu 22.04.5 and Nginx 1.30.5. We created one temporary public-text fixture, withheld file access to reproduce a permission-related 403, then permitted group read on that file and verified HTTP 200. It was removed afterwards. No application directory, access rule or global service setting was changed.
1. Identify the request and the layer denying it
Record hostname/path, time/timezone, status, request method, client context and recent changes. Check whether one file, a directory URL, all website pages or only an authenticated action is denied.
Cloudflare/WAF, Nginx and the application can each deny a request. A status or response logo is a clue, not proof of the source. A browser login failure may need account/application evidence rather than filesystem permissions.
For a harmless GET you control:
Replace the hostname/path; use curl.exe and NUL on Windows. Keep certificate validation enabled. Do not test protected data by bypassing an access policy merely to get a successful response.
2. Match the website's access and error logs
In our aaPanel interface: Website → PHP Project → the exact site's Log button → Access log / Error log. Confirm the source path and use Refresh. Read the website log guide for detailed searching and timestamp checks.
Our test request appeared as 403 in the access log. The corresponding Nginx error named the temporary text file and reported:
Code:
open() ... failed (13: Permission denied)
This supported a filesystem-access diagnosis for that static file. It was different from a missing file (404) or an undefined PHP function (500).
3. Inspect the exact file and its parent directories
Before a repair, record permissions, owner and group:
Code:
ls -l /path/to/affected-file
namei -l /path/to/affected-file
Use the actual path from the matching error. namei displays path components so you can inspect parent-directory traversal as well as the final file. Availability depends on your Linux tools.
A server needs appropriate read access to a served static file and search/traverse access to its parent directories. An unreadable file and a non-traversable parent require different targeted changes. ACLs and platform security controls can also affect access; mode bits alone do not explain every denial.
Our fixture's parents were traversable, and the denied file had mode 000 with owner root and group www. No parent permissions were changed during the test.
4. Confirm the process that needs access
Our Nginx master ran as root, but its workers ran as www:www. The worker identity is the relevant one for this static request; an administrator being able to read the file does not prove the web worker can.
A useful check that avoids full process arguments is:
Code:
ps -eo user,group,comm
Inspect the Nginx rows. Do not assume that every panel uses www: different services and PHP pools can run under different users. Ownership should follow your deployment model, not a blanket command copied from another server.
5. Apply the smallest justified permission change
For our existing fixture ownership root:www, mode 640 gave the owner read/write, the group read and others no access. Because the workers used group www, this permitted the intended static response without allowing them to write to the file.
Our one-file repair was equivalent to:
That path was our disposable text fixture. Before adapting the command, verify the intended owner/group and runtime identity, record the original mode and select only the affected file. It does not change ownership or grant a different group access.
This was a file-specific lab example, not a universal website permission preset. Other deployments may use another group or access model. A directory needs traversal permissions, so do not apply file mode 640 recursively to directories.
The existing guide Set File Permissions and Ownership in aaPanel covers the panel controls. Preserve the original mode/owner/group so a real repair can be reversed. Do not recursively apply chmod 777 or give a runtime write access to all application code just to eliminate a 403.
AdminsForum formatted transcript of the original experiment, not a panel screenshot.
6. Verify the response and new log evidence
After the targeted file change, the same URL returned HTTP 200 with the expected text. The access log recorded 200, no new error entry matched that file, and the normal homepage also returned 200.
No Nginx reload or restart was needed for this filesystem-mode change. If you instead edit a server configuration, validate it and use the supported reload procedure before testing its behavior.
We removed the temporary fixture after verification. The deliberately inaccessible file should not be left as a public test URL. Existing application files and permissions remained untouched.
7. Distinguish other 403 causes
The following are investigation examples, not failures induced in this test:
Directory URL denied: inspect the intended default document, running/document root and directory-index configuration. A missing expected index is not a reason to expose a directory listing of website files.
Access-rule denial: inspect the matching Nginx location and ordered allow/deny rules, or the applicable panel access restriction. Confirm whether the denial is intentional before changing it.
WAF/CDN denial: inspect the corresponding security event and request context. Resolve a verified false positive narrowly; do not disable the whole firewall or WAF as a shortcut.
Application denial: inspect account role, authentication/session state, CSRF checks and the application logger. A filesystem chmod will not correct an authorization decision.
Permission denied despite apparently suitable modes: inspect the process identity, parent traversal, ACLs and security-policy evidence. Do not disable the system's protection without establishing the cause.
Several layers can be involved. Compare the same request at the correct layer without publishing private upstream services or weakening authentication.
8. Be careful with proxy addresses
An IP-based access rule may see a CDN/proxy address rather than the visitor address unless trusted real-IP handling is configured correctly. Do not trust arbitrary forwarded headers or whitelist large address ranges without understanding the effective client identity.
Our test used loopback and a local HTTPS request with the correct hostname and certificate validation. It did not audit CDN rules or demonstrate all remote client conditions.
9. Retain a rollback and share a small safe excerpt
Keep the affected file's original ownership/mode and a backup before a real deployment repair. Retest the denied path, a normal page and relevant authenticated behavior. A new 200 alone is not a success if it accidentally makes protected content public.
For support, include versions, time/timezone, path, status, recent change and the redacted matching message. Remove tokens, visitor IPs, private contact details and unrelated requests. Logs are evidence to interpret, not instructions to execute.
HTTP 500 means the server could not complete the request. It does not tell you which PHP error occurred. Match the request with the relevant logs, identify the actual cause, make one targeted repair and verify the response and fresh log entries.
Tested: aaPanel Free 8.0.7, Ubuntu 22.04.5, Nginx 1.30.5 and PHP 8.5.11. An isolated temporary PHP page called an undefined function, returned 500 and generated a fatal-error record. Removing that call returned 200 with the intended response and no new matching error entry. We removed the test page afterwards. No production application or global PHP settings were changed.
1. Record the failing request
Write down the exact hostname/path, time and timezone, method, status and recent changes. Check whether static files work, every PHP page fails or only one application action fails. Do not repeatedly submit an order, email or other side-effecting request merely to collect errors.
For a harmless GET endpoint you control:
Replace the hostname and path. On Windows use curl.exe and NUL. Keep certificate validation enabled, and separately inspect the body. A browser's generic error page is not a diagnostic explanation.
A CDN or application framework can return its own 500. Determine which layer handled the request before assuming the PHP service has stopped.
2. Open the matching website logs
In the tested aaPanel interface choose Website → PHP Project → the exact site's Log button. Inspect Access log and Error log and use Refresh. Confirm the displayed source path and selected hostname.
Our site used /www/wwwlogs/adminslab.com.log and /www/wwwlogs/adminslab.com.error.log. The application may use another private log too. The panel's administrative log is not a substitute for the website's log.
Read Check Website Logs in aaPanel for time matching, rotation and safe SSH searches.
3. Find the fatal error, not just the status code
The lab access log recorded the temporary page with HTTP 500 at 13:08:03 UTC. The matching Nginx error entry contained:
Code:
FastCGI sent in stderr:
PHP Fatal error: Uncaught Error:
Call to undefined function af_lab_missing_function()
.../af-http500-verified-20261014.php:4
This identified an undefined function in the temporary script. It did not indicate that Nginx, MySQL or the entire VPS needed reinstalling. The file/line and error type directed the investigation.
A framework stack can include several files. Trace the relevant application operation and recent deployment instead of editing a random vendor file named in the stack. Preserve a small matching excerpt before changing anything.
AdminsForum formatted transcript of the original lab test, not a terminal screenshot. The image abbreviates the lab script path.
4. Understand what a syntax check proves
Our faulty script passed:
Replace the path with an actual file and use the intended installed PHP binary. This command checks PHP syntax without executing the normal application workflow. It did not detect that our function was unavailable when the request ran.
A successful lint does not establish runtime compatibility, autoloading, database access or correct application behavior. The CLI and PHP-FPM can also load different ini files and extensions. Verify the website's selected PHP version and its effective serving environment; do not change versions blindly to hide an error.
5. Repair the cause shown by the error
In our isolated demonstration, the repair was to remove the deliberately undefined call and return a fixed test message. We then repeated the same request. No service restart or pool increase was needed for this code error.
For a real application, first back up and use staging or a reversible deployment. Example investigations include:
Undefined function: check the function name, expected application include/autoloader or required extension. Determine which component supplies it before installing anything.
Class not found: inspect the deployment's dependencies and autoload configuration, including case-sensitive paths. Do not run arbitrary downloaded repair scripts.
Parse error: inspect the named file and recent edit, validate with the matching PHP version and deploy a corrected or known-good copy.
Memory exhausted: identify the request and resource cause. Raising memory limits without measurement may increase pressure across concurrent workers.
Database exception: inspect the application connection and matching database error; keep credentials out of public logs or support posts.
These are investigation examples, not additional failures triggered in this test. A 500 can have causes outside PHP as well; use the evidence actually recorded.
6. Keep diagnostics private and respect log-path restrictions
Use error logging rather than public stack traces. For the controlled request we kept display_errors off and log_errors enabled. Global settings may need to be set before execution to capture startup or parse failures; a line inside a script may not execute when parsing fails.
Our earlier attempt to choose a private custom log outside the website's allowed paths was blocked by open_basedir. The error appeared through FastCGI in the Nginx error log instead. We left the restriction intact and used the existing destination for the clean verification.
If a configured log is empty, check effective PHP settings, its permitted path and write permissions. Do not disable open_basedir globally or apply chmod 777 as a logging fix. Choose a supported private destination that the application's restrictions permit, or use the existing SAPI/application logger.
The FPM master log describes service diagnostics; it need not contain every application's fatal error. Avoid exposing phpinfo, debug logs or tokens on the website to discover a setting.
7. Verify HTTP status, content and fresh logs
At 13:08:06 UTC, the same temporary endpoint returned HTTP 200 and the text "AdminsForum clean recovery verified". Its access entry changed to 200, and there were no new error-log lines matching that page after the fix. The normal homepage also returned 200.
We allowed timestamp revalidation time before checking the changed file. If your deployment disables OPcache timestamp checking, use its approved invalidation/reload process; a browser refresh alone does not guarantee fresh PHP bytecode.
An old fatal entry remains historical evidence. Compare new timestamps and requests rather than clearing the log. Test an ordinary page and relevant application behavior, including reads/writes on staging where appropriate. A 200 with an error message in its body is not a complete recovery.
8. Clean up and retain a rollback
We removed both temporary diagnostic pages created during the experiment and retained private test records. Existing website content, PHP pool settings and security restrictions were unchanged.
Remove your own test files and temporary diagnostics after the observation window. Keep a known-good code/configuration backup and deliberate log retention. If a targeted change fails, restore it and verify service/application health again.
9. Distinguish a PHP 500 from a gateway failure
A 502 or upstream connection refusal may mean Nginx cannot get a usable upstream response. An executing PHP script's fatal error is a different finding. Correlate upstream service and website logs before choosing a fix.
For slow executing requests, use PHP-FPM slow logs; for shared-server pressure, use resource monitoring during a controlled test. Restarting everything can interrupt healthy services and hide useful evidence.
CloudPanel backups and security: remote backups, firewall and Basic Auth
The steps that protect a CloudPanel server: off-server backups, locking down the panel, per-site blocking, and keeping everything updated. Tested on CloudPanel 2.5.4, Ubuntu 24.04.
Part 1: Remote backups
A backup on the same server isn't a backup if the server dies. Go to Admin Area → Backups and choose a Storage Provider: Amazon S3, Wasabi, DigitalOcean Spaces, Dropbox, Google Drive, Hetzner Storage Box, SFTP or a custom Rclone config.
Turn on Enable Remote Backup and set the Frequency and Time. Pick a quiet hour, such as 02:00.
Enter the bucket and region, an access key and secret key, the storage directory, the retention period (days to keep) and any excludes such as cache folders, then save. (The keys in our screenshot are CloudPanel's example values, not real keys.) Create a key that can only access this one bucket.
Part 2: The firewall
In Admin Area → Security → Firewall, CloudPanel by default allows SSH (22), HTTP (80), HTTPS (443) and the panel (8443) from anywhere.
Best single step: allow port 8443 only from your own IP. Click Add Rule, type CloudPanel, source Custom, your IP with /32, and save. Add your rule first, then delete the rules that allow 8443 from anywhere, so you don't lock yourself out. Do the same for SSH if you have a fixed IP.
Part 3: Basic Auth in front of the panel
If your IP changes often, use Basic Auth instead (Admin Area → Security → Basic Auth). It puts a second username and password in front of CloudPanel's login page, which stops bots from even reaching it. As root you can also toggle it with:
Three tools you'll use on every CloudPanel site: cron jobs for scheduled tasks, the Logs tab for troubleshooting, and Varnish Cache for fast page loads. Tested on CloudPanel 2.5.4, Ubuntu 24.04.
Part 1: Cron jobs
Open the site's Cron Jobs tab and click Add Cron Job. The Template menu fills in common schedules for you, from every minute to once a month, or you can type the five fields yourself: minute, hour, day, month and weekday.
Example: a real cron for WordPress. WordPress's built-in cron only runs when someone visits the site. Run it every 5 minutes with real cron instead:
Then add this line to wp-config.php so WordPress doesn't also run it on page loads:
Code:
define('DISABLE_WP_CRON', true);
The job is saved and runs as the site user, with exactly the same permissions as the website.
Part 2: Logs
When something breaks, open the Logs tab. Choose the source (NGINX or PHP), the file (access or error) and how many lines to show, then click Update.
Each access-log line is one request: time, visitor IP, URL and status code. In our screenshot, a bot was probing for .env files (which can contain secrets) minutes after the site went live. That's normal on the internet, and a good reason to block bad bots in the site's Security tab.
Troubleshooting tip: for 500 errors or blank pages, check the PHP error log first; for 404s and redirects, the Nginx access log.
Part 3: Varnish Cache
Varnish stores finished pages in memory, so repeat visitors are served without running PHP at all. It's off by default; switch it on per site in the Varnish Cache tab.
Cache Lifetime: how long pages are kept.
Excluded Params: requests with these parameters bypass the cache (for example sessions).
When to use it: Varnish is a big win for blogs and content sites. For shops and member areas, test carefully: logged-in pages must never be cached for everyone. For WordPress, CloudPanel's CLP Varnish Cache plugin clears the cache when you publish.
Questions? Ask in CloudPanel Varnish Cache & Performance Support.
CloudPanel SSH, SFTP, FTP and File Manager: how to upload files
This guide covers every way to get files onto a CloudPanel site: the site user over SSH and SFTP, SSH keys, extra SSH and FTP users for developers, and the built-in File Manager, plus the one habit that prevents permission problems. Tested on CloudPanel 2.5.4, Ubuntu 24.04.
1. The site user: your main login
Every site already has one login: its site user. In the site's Settings tab you can reset its password, or paste your public SSH key to log in with a key instead of a password.
2. Log in over SSH
From your own computer:
Code:
ssh SITE_USER@YOUR_SERVER_IP
ls
# backups htdocs logs tmp
ls htdocs
# example.com
You land in the site user's home. Your website lives in htdocs/YOUR_DOMAIN. A site user can't see any other site.
3. Upload with SFTP (FileZilla, WinSCP, Cyberduck)
Use SFTP, not plain FTP:
4. Extra SSH and FTP users
Need to give a developer access without sharing the main login? Open the SSH/FTP tab → SSH Users → Add User. They get their own password or key, and you delete them when the job's done.
FTP Users work the same way, for older tools that only speak FTP. Plain FTP isn't encrypted, so prefer SFTP. If you do use FTP, you'll also need to allow the FTP and passive ports in the firewall (Admin Area → Security).
5. The File Manager
The File Manager tab works in your browser: upload, create, edit, rename, compress and extract files, and see the owner and permissions of each one. Everything is owned by the site user, which is exactly what PHP needs to write uploads and caches.
Avoid permission problems: don't work as root
Don't create site files as root over SSH. They'd be owned by root, and the site couldn't change them (failed uploads, cache errors, plugin updates that won't install). Always log in as the site user (or an extra SSH user for that site) and you'll never have permission problems.
Security tips
Prefer SSH keys over passwords.
Remove extra SSH/FTP users as soon as they're not needed.
If you have a fixed IP, restrict port 22 to it in Admin Area → Security → Firewall.
Questions? Ask in CloudPanel Users, SSH & SFTP Support.
CloudPanel databases: create a database and users, and use phpMyAdmin
In CloudPanel, databases belong to a site. This guide shows how to create a database and user, add extra users with limited rights, open phpMyAdmin, handle large imports from the command line, and where CloudPanel keeps automatic database backups. Tested on CloudPanel 2.5.4, Ubuntu 24.04, MySQL 8.4.
Step 1: Open the site's Databases tab
Open Sites → Manage → Databases. Our WordPress database is already listed, created by the one-click installer. Note the connection details at the top: host 127.0.0.1, port 3306. Your app uses these.
Step 2: Add a database
Click Add Database and enter a database name, a database user name and a password. CloudPanel creates both and grants the user access in one step.
Step 3: Add extra database users
The Database Users list shows every user, the database it can reach and its permissions. Use Add Database User for extra users, with Read and Write or Read Only access. A read-only user is ideal for reporting or backup tools, which then can never change your data.
Step 4: Open phpMyAdmin with one click
Click Manage next to a database user and phpMyAdmin opens already logged in as that user, with no extra password to type. Browse tables, run SQL, and import or export from the tabs at the top.
On the right, phpMyAdmin shows the server. On our install it's Percona Server 8.4, a drop-in MySQL build, chosen when we ran the installer.
Step 5: Big imports and exports with clpctl
Large databases can time out in the browser. As root, use clpctl instead:
Code:
# export a compressed dump
clpctl db:export --databaseName=my-database --file=/tmp/dump.sql.gz
# import a dump
clpctl db:import --databaseName=my-database --file=/tmp/dump.sql.gz
# create a database and user from the shell
clpctl db:add --domainName=example.com --databaseName=my-database --databaseUserName=myuser --databaseUserPassword='a-strong-password'
# show the database root (master) login
clpctl db:show:master-credentials
Automatic database backups
CloudPanel also dumps every database automatically each night (at 03:15 on our server) into the backups folder in the site user's home, and keeps 7 days of them. It's a useful safety net, but it's on the same server, so also set up remote backups in the Admin Area.
Tips
Give each app its own database user, and use read-only users wherever writing isn't needed.
Never expose port 3306 in the firewall; apps on the same server connect via 127.0.0.1.
Keep the master credentials for emergencies only.
Questions? Ask in CloudPanel Databases & phpMyAdmin Support.
Response times tell you that a site slowed down; simultaneous server measurements help explain why. This guide pairs a bounded WordPress traffic test with CPU, memory, swap and I/O observations on an aaPanel lab VPS.
Test environment: aaPanel Free 8.0.7, Ubuntu 22.04.5, two virtual CPUs and about 3.8GiB RAM, with Nginx, WordPress and PHP 8.5. The server also runs database, mail and other lab services. A separate Windows client generated traffic. We changed no server settings for this run.
1. Define the question before generating traffic
Are slow responses accompanied by CPU activity, memory pressure, storage waiting or application queueing? Choose a harmless lab endpoint and collect a baseline. Do not test destructive application actions or run an unlimited traffic loop.
Our test used the WordPress homepage with unique query strings. The existing FastCGI rules bypass query-string requests, verified in the earlier cache guide. A cached anonymous homepage could hide the PHP work we wanted to observe.
Start with the controlled load-test guide for request limits, TLS checks and timing definitions. This follow-up adds simultaneous resource evidence rather than repeating a capacity claim.
2. Capture memory and load snapshots
On the lab server, use a private SSH session:
Code:
date -Is
uptime
free -h
cat /proc/meminfo
Record the clock and timezone. The client and server must have reasonably aligned clocks to correlate events. Low free memory alone does not demonstrate a problem; include available memory and swap activity. A load average is also not a direct CPU percentage.
Our MemAvailable snapshots were 2,849,192KiB before and 2,813,252KiB after, approximately 2.72GiB and 2.68GiB. These are two snapshots, not the minimum available memory throughout the run.
3. Start a finite interval sampler
Our existing vmstat utility required no additional package installation. We ran:
Code:
LC_ALL=C vmstat -n -t 1 25
This requests one-second updates and a finite count. Keep the output in a private administration session or log, and note the sampler's start/end time. It should overlap the request phases, not run only after the workload finishes.
The first data row includes activity averages since boot. We excluded it from interval summaries. Process and memory columns are snapshots; later activity columns cover the sampling interval. In this run we retained 24 interval rows across the traffic and surrounding idle time.
4. Understand the useful columns
r: runnable work; compare repeated values with the CPU count, not one isolated spike.
b: work blocked waiting for I/O completion.
us and sy: user and kernel CPU percentages. Our CPU activity summary used 100 minus idle, I/O wait and steal.
id, wa and st: idle, I/O-wait and virtual-machine steal percentages; these describe different conditions.
si and so: swap-in and swap-out activity. Existing swap usage without current transfers is different from sustained swapping.
bi and bo: block input/output activity. These alone do not identify which disk or application is responsible.
Check the local manual for units and version details. Small one-second samples can hide shorter spikes, while whole-server measurements combine activity from every service.
5. Run a bounded client workload
We used 80 requests at concurrency 4, followed by 80 at concurrency 8. Every request used HTTPS with normal certificate validation, a 15-second maximum time and no retry. The run would stop before a later phase if any request failed or its sample p95 TTFB exceeded five seconds.
The generator ran off the VPS, so its local client work did not consume the VPS CPUs being measured. It used a finite worker pool: after one request completed, a worker could submit another. This closed-loop workload does not reproduce every real traffic pattern.
Keep important service health under observation and stop if your lab becomes unstable. Do not increase concurrency just to force a failure.
6. Compare the recorded results AdminsForum formatted transcript of the original measurements, not a terminal screenshot.
Concurrency 4: 80/80 HTTP 200, median TTFB 313ms, sample p95 467ms, elapsed phase about 10.20 seconds.
Concurrency 8: 80/80 HTTP 200, median TTFB 414ms, sample p95 539ms, elapsed phase about 5.76 seconds.
Across the 24 resource intervals: CPU activity peaked at 88%, I/O wait at 0%, steal at 1%, and runnable work at 6.
Every interval reported zero swap-in and zero swap-out; available-memory snapshots remained about 2.7GiB.
The higher-concurrency phase completed its finite batch sooner but had higher median latency. These short phases were not repeated in randomized order, and other lab services may contribute to whole-server CPU activity.
The resource summary includes idle time around the test. Its peak values should not be confused with a phase average. We did not measure FPM queue lengths, individual query timing, per-process CPU attribution or device latency in this run.
7. Form a hypothesis without overstating it
The observations do not show sampled swap pressure or I/O-wait activity. CPU work is a plausible next investigation because activity increased during this request workload. They do not prove that CPU is the only bottleneck or that the VPS can sustain this traffic indefinitely.
For a stronger diagnosis, correlate process CPU, private FPM queue/status observations and application timings with the same request timestamps. Read the PHP slow-log guide to locate executing requests and the database index guide when SQL is implicated.
If storage is suspected, collect device-level latency and queue information as a separate test. A sampled wa value of zero is not proof that every storage operation was instantaneous.
8. Choose the next change from evidence
CPU-heavy PHP work may benefit from application improvements or appropriate caching; adding workers can increase contention. Memory pressure calls for examining actual process use and service budgets. Slow SQL calls for a query plan, not an arbitrary increase to max_connections.
Change one variable, retain a rollback copy and repeat the same workload with the sampler running. Check content correctness and errors as well as speed. HTTP 200 alone cannot establish that an application returned the intended page.
9. Keep the test reproducible
Save phase times, raw request outcomes, resource intervals and configuration versions. Keep logs private and remove secrets before sharing. Use representative authenticated and write workflows only in an appropriate disposable test environment.
This test added no public diagnostic endpoint, altered no application data and left server settings unchanged. Longer runs and realistic workload mixes remain necessary for production planning.
Start website troubleshooting by recording the failing request, its time and its HTTP status. Then match that request with the website's access log, error log and application evidence. This guide shows a real missing-file diagnosis in aaPanel and explains where to look for other failures.
Tested: aaPanel Free 8.0.7, Ubuntu 22.04.5 and Nginx 1.30.5. We inspected the native website log viewer, generated one missing-file request, matched its access/error entries and verified a temporary file corrected that request. The test file was removed afterwards. Other error types below are interpretation examples, not deliberately triggered failures.
1. Write down the symptom before changing anything
Record the exact hostname and path, time with timezone, HTTP status, request method, whether all pages fail or one route fails, and the last relevant change. Distinguish a browser connection failure from an HTTP response delivered by a server.
A request may pass through Cloudflare/CDN, Nginx, PHP-FPM and the application. A status code alone does not identify which layer caused it. Avoid restarting every service before collecting the relevant evidence.
For a harmless GET endpoint you control:
Replace the hostname and path. Keep certificate verification enabled. This Linux example shows headers and discards the body; on Windows use curl.exe and NUL. Separately inspect the response content, because HTTP 200 can still contain an application error.
2. Open the website's native aaPanel logs
In our current interface:
Open Website and select PHP Project.
Find the exact site row and click Log.
The Site modification window provides Access log and Error log views, alongside Response log and Log Security Analysis.
Use Refresh to retrieve current information. The access view offers recent 50, 100, 500 or All lines and displays the source log path.
Labels differ between versions and project types. The main left-menu Logs section is a separate panel-wide entry; do not assume its administrative log is the website's application log. Node/Python projects have their own runtime logging to inspect as well.
Our website access log was /www/wwwlogs/adminslab.com.log; its error log was /www/wwwlogs/adminslab.com.error.log. These are lab paths, not universal names. Confirm the selected website and effective Nginx access_log/error_log directives if the viewer shows no matching entries.
3. Locate the request in the access log
The access log tells you that the server handled a request and records configured fields such as method, path, status and byte count. Our matching entry contained:
Code:
[14/Oct/2026:12:40:54 +0000]
GET /af-log-troubleshooting-missing-20261014.txt HTTP/2.0
404
The full entry used loopback client 127.0.0.1 because our request came from the server itself. For proxied visitor traffic, an address in a log may identify the proxy unless trusted real-IP handling is configured. Do not treat arbitrary forwarded headers as verified visitor identity.
Match the time, hostname, path and method rather than assuming the latest error belongs to your browser. Check browser/CDN caching and timezone differences when the times seem inconsistent.
4. Match the error log at the same time
At 12:40:54 UTC, our error log reported an open() failure for the expected file under /www/wwwroot/adminslab.com, with error 2: No such file or directory.
This supported a missing-file diagnosis for this static test URL. We created only that temporary file at the expected root path and repeated the request. At 12:41:34 UTC the response was HTTP 200 with the intended test content, and the access log recorded 200.
AdminsForum formatted transcript of our synthetic request and matching log entries, not a screenshot. Unrelated visitor entries are excluded.
We removed the fixture after verification. This was a lab demonstration, not a recommendation to create an empty file whenever a route returns 404. An application route may instead require the right document root or rewrite rules. For WordPress pretty URLs, see the permalink 404 guide.
5. Read common messages as clues
No such file or directory: inspect the exact path, document root, deployment contents or upstream socket named by the message. A missing static file and a missing FPM socket have different fixes.
Permission denied: identify the object, runtime user and required access. Review ownership, parent-directory traversal and applicable security controls; do not recursively apply chmod 777.
Connection refused while connecting to upstream: inspect the configured upstream and whether the intended service is listening. Check its own error/startup logs before restarting it.
Upstream timed out: investigate the upstream's workload and dependencies. Raising a timeout without finding the delay can keep resources occupied longer.
PHP fatal/uncaught exception: locate the application stack and matching runtime log, then review the relevant code, dependency and recent change. A 500 is not always a PHP syntax error.
These are example interpretations. Use the complete message and request context. For 502 troubleshooting, correlate web-server and upstream evidence; do not use HTTP curl against a FastCGI socket as though it were an HTTP endpoint.
6. Know the difference between PHP-FPM and application logs
The lab FPM master error_log was /www/server/php/85/var/log/php-fpm.log. This captures FPM service diagnostics; it is not a guarantee that every PHP application's warning appears there.
A private FPM settings probe confirmed PHP loaded /www/server/php/85/etc/php.ini, with log_errors enabled, display_errors off and no explicit PHP error_log path. An empty PHP error_log value delegates the destination to the SAPI. Inspect the effective runtime, web-server FastCGI error output and application logger rather than assuming a file name.
The CLI runtime can load a different ini file. Never publish phpinfo or stack traces on an unprotected website just to discover a setting. Our probe was outside the web root, used through the private socket and removed afterwards.
PHP slow logs answer a different question: where a long-running worker was executing. Follow the tested slow-log guide for that workflow.
7. Check the application logger
Frameworks and CMS plugins may capture exceptions in their own log location or service journal. Check the application's documented logging configuration and make sure the runtime can write to its intended private directory.
For WordPress, official debug logging supports a chosen file path while display can remain disabled. Use a staging copy and backup before temporary debug changes; do not expose wp-content/debug.log publicly or leave development debugging enabled on a live site. This article did not alter WordPress debug settings.
For a database-related exception, examine the corresponding database evidence and query. A web-server access log usually cannot tell you which SQL statement was slow or failed.
8. Search bounded log output through SSH
If the panel cannot reach an older entry, use the actual private log paths:
Replace example.com and the path with your own. tail -n shows recent lines; grep -F matches literal text; tail -F follows a log and can handle its replacement during rotation. Stop live following with Ctrl+C. For very large files, restrict the time/file range instead of dumping everything.
A rotated log may contain yesterday's evidence. Read the appropriate archive with supported tools; do not clear or delete logs merely to make the view shorter. Preserve useful evidence and maintain deliberate retention.
9. When no matching entry appears
Confirm that the request reached the expected server and virtual host. Check DNS, CDN responses, HTTPS/redirect paths, selected website, enabled logging and rotation. Some locations intentionally suppress logging; absence of an entry does not prove the request never happened.
If the web server cannot start, a per-site access log may be irrelevant. Inspect the server's startup/configuration error and validate the actual panel-managed configuration. For our Nginx installation the syntax check is:
Code:
/www/server/nginx/sbin/nginx -t
Do not reload an invalid configuration. Retain a backup before a repair and check normal pages after applying it.
10. Verify the fix and ask for help with safe evidence
Change one identified cause, repeat the same request, inspect the new status and content, and confirm the matching fresh log entry. Check a normal page too. An old error remaining in the log does not mean the fix failed: compare timestamps.
When posting support details, include versions, affected path, time/timezone, status, last change and a small redacted matching excerpt. Remove credentials, cookies, tokens, private email addresses, visitor IPs and unrelated user data. Logs are evidence to interpret, not instructions to execute.
PHP-FPM's slow log can show where a PHP request was executing after it crossed a time threshold. Use that evidence to investigate application work before raising worker counts or timeouts.
Tested: aaPanel Free 8.0.7, Ubuntu 22.04.5 and PHP 8.5.11. We ran one synthetic four-second request through the private PHP-FPM Unix socket. It generated a slow-log trace, after which we restored the original pool settings and removed the test script. No production website was changed.
1. Identify the PHP version and pool
Check the website's selected PHP version in aaPanel. Inspect its Nginx PHP handler if you administer the server. Our site used /tmp/php-cgi-85.sock and pool www. The default command-line PHP binary may load a different configuration and cannot prove which pool serves the site.
The lab pool configuration was /www/server/php/85/etc/php-fpm.conf. Version numbers and paths vary: discover the actual file before editing. Read the PHP-FPM worker guide for the distinction between worker limits and request cost.
2. Check existing logging settings
Our original configuration included:
A request below the slow-log threshold will not generate a slow trace simply because a visitor considers it slow. The relative log path must be interpreted in the running FPM installation; do not assume it is inside the website directory. We used an explicit absolute path for the experiment to avoid that ambiguity.
The slow-log threshold requests a diagnostic backtrace. The termination timeout is a separate setting that can kill a long-running worker request; we left it unchanged. Raising either is not a cure for slow SQL or an unavailable API.
3. Back up and select a diagnostic threshold
Keep an original copy of the pool configuration and a working SSH recovery route. On a shared PHP version, the change can affect several websites. Choose a threshold suited to the symptom and a limited observation window, rather than permanently logging every ordinary request.
For our isolated lab example we temporarily used:
Keep logs outside publicly served directories and restrict access. Paths and stack traces can reveal implementation details. Use your own private log path and ensure the FPM master can open it; avoid broad permission changes such as chmod 777.
4. Validate before reloading
On this lab installation:
The configuration test passed. Reload only after success and inspect application health afterwards. Use the service names and binary for your selected version. A valid configuration does not guarantee the diagnostic backtrace will succeed on every container or host; inspect FPM errors if tracing is restricted.
5. Generate one controlled slow request
Our test script contained only:
It was stored outside the website root and executed through cgi-fcgi over /tmp/php-cgi-85.sock using a local administrator session. The request had a client timeout and completed in about 4.004 seconds. We did not publish a slow test URL, start a traffic loop or trigger real customer actions.
If reproducing this lesson, use an isolated lab and its actual private socket. Do not upload a deliberate delay script to a public production website. For a real symptom, collect traces from a bounded legitimate test workflow instead.
AdminsForum formatted transcript of the original lab result, not a terminal screenshot. The image abbreviates the private diagnostic path.
6. Read the trace
The log named pool www and the test script, then identified sleep() on line 1. That is consistent with the intentional waiting operation. It confirms that slow logging worked for this request.
A trace is a snapshot of execution, not a complete timeline or a ranked profiler. A function visible in one sample is not automatically the root cause. Compare several relevant traces and correlate the request time with application, database and web-server evidence.
7. Follow the evidence to the right component
A database call in the trace: identify the corresponding query and inspect its plan and database timing. Follow the EXPLAIN and index test guide.
An HTTP/API operation: inspect destination latency, connection errors and application timeout handling. Do not repeatedly retry a side-effecting request just to gather samples.
Repeated application functions: use a suitable application profiler in a controlled environment and compare expensive paths. The slow log alone does not quantify every function's cost.
Many occupied workers: combine traces with CPU, memory and FPM queue observations. Queueing before a request starts running in a worker may not be explained by its eventual slow trace.
A full-page cache HIT may bypass PHP entirely. Use the cache verification guide to distinguish that path from a PHP request. Do not infer that logging is broken solely because cached pages produce no PHP trace.
8. Restore and verify
Our test restored the original configuration byte for byte, validated it and reloaded the service. We removed the temporary script and retained the private trace and backup for documentation. The original 30-second threshold and existing log path were restored; the termination limit was unchanged.
After your diagnostic window, restore the previous settings or choose a deliberate long-term policy with log retention and disk monitoring. Keep raw traces private and redact paths and user-related details before asking for public help.
9. Retest the actual fix
Change one identified cause, repeat the same meaningful workflow and compare response time, errors and resource use. Keep a rollback plan. Disabling diagnostics, adding workers or increasing a timeout without evidence does not establish that the cause was fixed.
