AdminsForum - All Forums

Fix 413 Request Entity Too Large Errors in aaPanel

Thu, 15 Oct 2026 11:34:38 +0800

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.

nginx-413-20261015.jpg (Size: 124.89 KB / Downloads: 3)
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.

References: Nginx client_max_body_size and PHP POST-size configuration.

Fix 403 Forbidden Errors in aaPanel Using Logs

Wed, 14 Oct 2026 21:18:55 +0800

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:

Code:

curl -sS --max-time 15 -D - -o /dev/null https://example.com/affected-path

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:

Code:

chmod 640 /www/wwwroot/adminslab.com/af-http403-lab-20261014.txt

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.

http403-permission-20261014.jpg (Size: 131.87 KB / Downloads: 4)
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.

References: GNU file-mode structure, Nginx access rules and Nginx directory listings.

Fix PHP HTTP 500 Errors in aaPanel Using Error Logs

Wed, 14 Oct 2026 21:11:00 +0800

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:

Code:

curl -sS --max-time 15 -D - -o /dev/null https://example.com/problem-page

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.

php-http500-20261014.jpg (Size: 133.63 KB / Downloads: 6)
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:

Code:

/www/server/php/85/bin/php -l /path/to/the/affected-file.php

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.

Reference: Official PHP error logging configuration.

CloudPanel Backups and Security: Remote Backups, Firewall and Basic Auth

Wed, 14 Oct 2026 21:10:47 +0800

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.

  g7-01-ae55.jpg (Size: 87.42 KB / Downloads: 3)

Turn on Enable Remote Backup and set the Frequency and Time. Pick a quiet hour, such as 02:00.

  g7-02-ae56.jpg (Size: 112.26 KB / Downloads: 3)

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.

  g7-03-ae57.jpg (Size: 113.31 KB / Downloads: 3)

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.

  g7-04-ae58.jpg (Size: 104.35 KB / Downloads: 3)

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.

  g7-05-ae60.jpg (Size: 103.36 KB / Downloads: 3)

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:

Code:

clpctl cloudpanel:enable:basic-auth --userName=john --password='a-strong-password'
clpctl cloudpanel:disable:basic-auth

g7-06-ae61.jpg (Size: 89.63 KB / Downloads: 3)

Part 4: Site-level security
Each site has its own Security tab:

IP Blocking: block single IPs or whole ranges.
Bot Blocking: block bad bots by user agent, such as the scanners you'll see in your access logs.

g7-07-ae40.jpg (Size: 96.39 KB / Downloads: 3)

Basic Authentication: password-protect staging copies the public shouldn't see, with a list of whitelisted IPs that skip it.
Cloudflare: "Allow traffic from Cloudflare only", so nobody can bypass Cloudflare by hitting your server's IP directly.

g7-08-ae42.jpg (Size: 84.98 KB / Downloads: 3)

Part 5: Keep everything updated

Code:

apt update && apt -y upgrade
# take a snapshot of the server at your provider first
clp-update
reboot   # when a new kernel was installed

Security checklist

Remote backups on, with a tested restore.
Port 8443 restricted to your IP, or Basic Auth enabled.
Two-factor authentication on your CloudPanel admin user.
SSH keys instead of passwords; SSH restricted if you have a fixed IP.
Bad bots and abusive IPs blocked per site; Cloudflare-only mode if you use Cloudflare.
OS and CloudPanel updated regularly.

Questions? Ask in CloudPanel Security Support.

CloudPanel guide series

What is CloudPanel? Complete overview
CloudPanel system requirements
CloudPanel features: the complete list
How to create a PHP site
How to install free Let's Encrypt SSL
How to install WordPress (one-click)
Databases, users and phpMyAdmin
SSH, SFTP, FTP and File Manager
Cron jobs, logs and Varnish Cache
Backups, firewall and Basic Auth (you are here)

CloudPanel Cron Jobs, Logs and Varnish Cache: Complete Guide

Wed, 14 Oct 2026 21:10:14 +0800

CloudPanel cron jobs, logs and Varnish Cache

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.

g6-01-ae47.jpg (Size: 98.57 KB / Downloads: 3)

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:

Template: Every 5 minutes (

Code:
*/5 * * * *
)
Command:

Code:
php /home/SITE_USER/htdocs/YOUR_DOMAIN/wp-cron.php > /dev/null 2>&1

g6-02-ae48.jpg (Size: 103.82 KB / Downloads: 3)

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.

g6-03-ae52.jpg (Size: 101.13 KB / Downloads: 3)

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.

g6-04-ae50.jpg (Size: 148.44 KB / Downloads: 3)

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).

g6-05-ae39.jpg (Size: 103.92 KB / Downloads: 3)

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 guide series

What is CloudPanel? Complete overview
CloudPanel system requirements
CloudPanel features: the complete list
How to create a PHP site
How to install free Let's Encrypt SSL
How to install WordPress (one-click)
Databases, users and phpMyAdmin
SSH, SFTP, FTP and File Manager
Cron jobs, logs and Varnish Cache (you are here)
Backups, firewall and Basic Auth

CloudPanel SSH, SFTP, FTP and File Manager: How to Upload Files

Wed, 14 Oct 2026 21:09:43 +0800

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.

g5-01-ae10.jpg (Size: 76.29 KB / Downloads: 3)

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:

Code:

Protocol: SFTP
Host:     YOUR_SERVER_IP
Port:     22
User:     SITE_USER  (password or SSH key)
Folder:   /home/SITE_USER/htdocs/YOUR_DOMAIN

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).

g5-02-ae43.jpg (Size: 97.02 KB / Downloads: 3)

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.

g5-03-ae45.jpg (Size: 132.72 KB / Downloads: 3)

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 guide series

What is CloudPanel? Complete overview
CloudPanel system requirements
CloudPanel features: the complete list
How to create a PHP site
How to install free Let's Encrypt SSL
How to install WordPress (one-click)
Databases, users and phpMyAdmin
SSH, SFTP, FTP and File Manager (you are here)
Cron jobs, logs and Varnish Cache
Backups, firewall and Basic Auth

CloudPanel Databases: Create a Database, Users and Use phpMyAdmin

Wed, 14 Oct 2026 21:09:13 +0800

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.

  g4-01-ae34.jpg (Size: 103.25 KB / Downloads: 4)

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.

  g4-02-ae36.jpg (Size: 104.64 KB / Downloads: 4)

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.

  g4-03-ae38.jpg (Size: 178.15 KB / Downloads: 4)

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.

g4-04-ae45.jpg (Size: 132.72 KB / Downloads: 4)

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.

CloudPanel guide series

What is CloudPanel? Complete overview
CloudPanel system requirements
CloudPanel features: the complete list
How to create a PHP site
How to install free Let's Encrypt SSL
How to install WordPress (one-click)
Databases, users and phpMyAdmin (you are here)
SSH, SFTP, FTP and File Manager
Cron jobs, logs and Varnish Cache
Backups, firewall and Basic Auth

Monitor Server Resources During aaPanel Website Traffic Tests

Wed, 14 Oct 2026 20:51:09 +0800

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

monitor-load-20261014.jpg (Size: 128.09 KB / Downloads: 7)
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.

Reference: Ubuntu vmstat manual.

Check Website Logs in aaPanel to Troubleshoot Site Errors

Wed, 14 Oct 2026 20:48:47 +0800

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:

Code:

curl -sS --max-time 15 -D - -o /dev/null https://example.com/problem-path

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.

log-troubleshooting-20261014.jpg (Size: 129.35 KB / Downloads: 6)
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:

Code:

tail -n 100 /www/wwwlogs/example.com.error.log
grep -F -- '/problem-path' /www/wwwlogs/example.com.log
tail -F /www/wwwlogs/example.com.error.log

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.

References: Nginx beginner's guide, PHP error logging configuration and WordPress debugging documentation.

Find Slow PHP Requests in aaPanel with PHP-FPM Slow Logs

Wed, 14 Oct 2026 20:35:09 +0800

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:

Code:

request_slowlog_timeout = 30
slowlog = var/log/slow.log
request_terminate_timeout = 100

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:

Code:

request_slowlog_timeout = 2
slowlog = /www/server/php/85/var/log/af-slowlog-lab-20261014.log

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:

Code:

/www/server/php/85/sbin/php-fpm -t
/etc/init.d/php-fpm-85 reload

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:

Code:

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.







  php-slowlog-20261014.jpg (Size: 111.23 KB / Downloads: 7)


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 componentA 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.



Reference: Official PHP-FPM configuration documentation.



Verify WordPress FastCGI Cache Hits and Bypass Rules in aaPanel
Wed, 14 Oct 2026 20:24:21 +0800
FastCGI page caching can let Nginx answer an anonymous request without running PHP. Verify both cache hits and exclusions before relying on it: private or personalized responses must not be served from a shared anonymous cache.



Scope: We tested an existing WordPress FastCGI cache in aaPanel Free 8.0.7 with Nginx and PHP 8.5. This guide verifies the existing setup; it does not claim we installed a new cache or fully audited every authenticated workflow.



1. Identify the cache layer

Page caching stores a rendered HTTP response. OPcache stores compiled PHP bytecode; Redis object caching stores application objects. They solve different problems. A page-cache HIT may avoid PHP, so it cannot be used to measure PHP or SQL tuning alone.

Inspect the website's Nginx configuration and included PHP handler. Our WordPress site included enable-php-85-wpfastcgi.conf and used a WORDPRESS FastCGI cache zone.



2. Read the rules before testing

Our existing rules bypassed POST requests, nonempty query strings, WordPress administrative/login-related paths and cookies matching WordPress login or password-protected content. These rules must be checked against the actual applications on the site.

The handler used both:

Code:
fastcgi_cache_bypass $skip_cache;
fastcgi_no_cache $skip_cache;
The first controls whether an existing cached response is used; the second controls whether the upstream response is stored. A correct private-response policy needs both aspects considered. Do not copy an incomplete location block or override application Set-Cookie behavior blindly.



3. Inspect cache headers

Our configuration exposed Nginx-Cache with the upstream cache status. Your site may use another header or expose none.

Code:
curl -sS -D - -o /dev/null https://example.com/
Replace the hostname. Read the HTTP status and cache header. HIT means a stored response was served. MISS means the cache did not supply an entry; an eligible response may subsequently be stored. BYPASS means the rules skipped reading the cache. Absence of a header does not prove caching is disabled.



4. Repeat an anonymous request

We sent five sequential requests to the same lab homepage over loopback HTTPS with certificate validation. All five returned HTTP 200 and HIT; median time to first byte was approximately 58ms.

The page was already cached. We did not claim to demonstrate a fresh MISS-to-HIT transition, clear the whole cache or measure maximum throughput. Five requests are a small diagnostic sample.



5. Check query and cookie exclusions

Code:
curl -sS -D - -o /dev/null 'https://example.com/?cache_check=1'
curl -sS -D - -o /dev/null \
  -H 'Cookie: wordpress_logged_in_lab=synthetic-test' https://example.com/
curl -sS -D - -o /dev/null https://example.com/wp-login.php
The query-string request, synthetic login-cookie request and login page each returned HTTP 200 and BYPASS in our lab. The synthetic cookie contains no real login token; it tests the configured cookie-name rule only. It does not authenticate a user or prove actual account privacy end to end.







  cache-performance-20261014.jpg (Size: 105.63 KB / Downloads: 5)


AdminsForum formatted transcript of the original checks, not a screenshot.



6. Test actual personalized workflows before rollout

With a controlled test account, verify that logged-in pages, shopping carts, checkout, account settings and password-protected content are excluded. Test two separate sessions and inspect rendered content, not just a fast response. Review authorization, cookies, cache keys and application-specific paths.

Our short check did not perform these authenticated workflows. Treat them as required verification before enabling shared page caching for a real personalized application.



7. Verify freshness and controlled purging

After updating a public test page, confirm when anonymous visitors receive the new content. Purge the relevant cache entry using your supported administration workflow and verify the result. Do not expose an unrestricted public purge endpoint.

Our existing configuration restricted its purge location to loopback. We did not weaken that restriction or perform a global purge for this guide. Cache lifetime and invalidation should match how frequently your pages change.



8. Troubleshoot a persistent BYPASS or stale page

Check whether a query string, cookie, request method or path matches an exclusion. Inspect the effective Nginx configuration and logs. If a public page bypasses unexpectedly, identify the cause rather than deleting all exclusions.

For stale content, check the correct hostname, cache key, purge method and any additional CDN or browser cache. A browser refresh alone may leave server caches untouched.

Back up before changing rules, validate Nginx syntax, reload and repeat both anonymous and private-response tests. Restore the original rules if personalized content is cached or application behavior changes.



Reference: Official Nginx FastCGI cache controls.


Run a Controlled WordPress Load Test on an aaPanel VPS
Wed, 14 Oct 2026 20:22:42 +0800
A controlled load test helps compare one workload at several concurrency levels. It does not prove how many visitors an entire website can support. This guide records a bounded external-client test and explains the measurements still needed for a production decision.



Environment: two-CPU shared Ubuntu VPS, aaPanel Free 8.0.7, Nginx, WordPress and PHP 8.5. The tested FPM pool had a maximum of eight children and OPcache enabled. Existing FastCGI cache rules bypassed query-string requests. The generator ran on a separate Windows machine.



1. Choose a safe target and scope

Use a lab server you control. Choose a harmless GET endpoint and a finite request count. Exclude actions that create accounts, orders, mail or database writes. Agree a maintenance window for production testing and monitor other services sharing the machine.

Our target was the WordPress homepage with a unique test query on each request. We verified the query rule returned Nginx-Cache: BYPASS before the run. This measures an uncached homepage path, not checkout, search, login or an entire browsing session.



2. Record the baseline and configuration

Write down PHP version, FPM worker limits, cache states, database version and application version/plugins. Keep those constant between phases. Record server memory, swap and CPU before testing; arrange an interval resource sampler if you need to locate saturation.

This run did not collect a simultaneous server resource trace. We therefore report response results without claiming whether PHP, CPU or SQL limited throughput.



3. Set explicit limits and stop conditions

Our client used 40 requests per phase at concurrency 2, then 4, then 8. Each curl request had a 15-second maximum time, used normal HTTPS certificate validation and performed no retries. Later phases would stop if any request failed or the sample p95 time to first byte exceeded five seconds.

A short request count bounds the total work but can miss sustained bottlenecks. Avoid unbounded loops and high concurrency simply to generate a dramatic result. Watch availability and stop manually if important services degrade.



4. Understand the client measurements

A single request example is:

Code:
curl.exe -sS --max-time 15 -o NUL \
  -w "%{http_code} %{time_starttransfer} %{time_total}" \
  "https://example.com/?load_test=unique_value"
This is a Windows example: NUL discards the body. Use /dev/null on Linux. Replace the hostname and make each test query unique if your verified rules use query strings to bypass caching. Do not disable certificate checks.

Time to first byte includes client-side connection and network effects as well as server waiting. Total time includes body transfer. An HTTP 200 alone does not prove the content is correct; separately inspect a sample response for application errors.

We used a bounded client worker pool to run the finite requests concurrently, waited for each phase to complete, then calculated its results. These are closed-loop tests: workers submit another request after the previous one finishes, rather than maintaining a fixed independent arrival rate.



5. Read the actual results





  load-performance-20261014.jpg (Size: 124.63 KB / Downloads: 5)


AdminsForum formatted transcript of the original client test, not a screenshot.

Concurrency 2: 40/40 HTTP 200; median TTFB 295ms; sample p95 334ms; phase elapsed 8.46 seconds; about 4.73 completed requests/second.


Concurrency 4: 40/40 HTTP 200; median TTFB 334ms; sample p95 431ms; phase elapsed 4.91 seconds; about 8.15 completed requests/second.


Concurrency 8: 40/40 HTTP 200; median TTFB 377ms; sample p95 609ms; phase elapsed 2.88 seconds; about 13.87 completed requests/second.



All 120 requests completed with HTTP 200 and no client request failure. Concurrency increased the observed completion rate and latency. The phases were short, were not repeated in randomized order, and did not isolate cache-warmth or resource effects. Do not interpret the numbers as a guaranteed sustained rate or maximum visitors.

The sample p95 is a nearest-rank estimate from forty observations, not a precise long-term tail metric. Network variation and shared-server activity can affect it.



6. Add resource evidence before tuning

For a repeat test, sample CPU utilization, iowait, free memory, swap activity, FPM queues and active database work throughout the phases. Private FPM status and slow logs can help locate queueing. Keep diagnostic endpoints private and redact logs before sharing.

If latency rises with CPU saturation, more FPM workers may worsen contention. If queries dominate, inspect SQL plans. If the client itself is saturated, the generator may be the limit. These conclusions need measurements; this run does not establish them.



7. Repeat a representative workload

Use the same test after one targeted change. Include realistic page mixes, authenticated workflows under controlled accounts, writes in a disposable environment and sustained runs appropriate to your service. Measure errors and content correctness alongside latency.

Test anonymous cache HIT and uncached behavior separately. A fast cached homepage cannot prove that private or dynamic pages perform well. Never increase a pool limit solely because a cached benchmark looks good.



8. Preserve results and restore experimental changes

Keep raw request outcomes, timing definitions and configuration snapshots. Remove only your own disposable fixtures when no longer needed. Retain rollback copies for settings changed during earlier tests. This load run itself changed no server configuration or website content.



Use the baseline guide, the measured PHP-FPM pool guide and the database index test as a repeatable series. Present the workload and its limits whenever quoting performance numbers.


Test Nginx Performance and Gzip Compression in aaPanel
Wed, 14 Oct 2026 20:21:21 +0800
Nginx tuning should start with measurements, not a list of larger limits. This guide checks worker settings and gzip behavior, demonstrates a real compression tradeoff, and explains when to restore a change.



Tested: aaPanel Free 8.0.7, Nginx 1.30.5 and Ubuntu 22.04.5 on the shared two-CPU lab VPS. No production configuration was changed.



1. Inspect the active configuration

Open App Store → Installed → Nginx → Setting and inspect its configuration. Paths and interface labels can differ by release. Our global file was /www/server/nginx/conf/nginx.conf; website configurations were included separately.

A configuration dump can help identify includes:

Code:
/www/server/nginx/sbin/nginx -T
Keep the output private because it can reveal hostnames, paths and configuration details. Identify which file owns the directive before editing it.



2. Review workers and connection limits

Our server already used worker_processes auto and worker_connections 51200. We did not increase either. More permitted connections do not mean more requests per second: upstream connections, open-file limits, PHP workers, database work and CPU also constrain throughput.

Inspect actual worker count, active connections, system file limits and errors during representative traffic. Raise a limit only if it is the observed bottleneck and the server has resources to support it. Avoid treating a high worker_connections value as a visitor-capacity guarantee.

Keepalive settings also need workload evidence. Shorter idle time can reduce held connections but increase connection setup; longer idle time can retain resources. We left the existing 60-second setting unchanged.



3. Back up before a compression experiment

Make a private copy of the active file. Our baseline already had gzip enabled, a 1KiB minimum length, compression level 5 and gzip_vary on. Its gzip_types included text, JavaScript, CSS, JSON and several image types.

Inspect response headers and actual transfer sizes before changing MIME types. Many image formats contain compressed data, but the effect of an additional gzip layer depends on the particular file.



4. Test text and image responses

We created an original 24,500-byte text fixture in the lab website and used an existing 3,113-byte WordPress PNG. We requested gzip explicitly over loopback HTTPS with normal certificate validation.

A basic header check is:

Code:
curl -sS -D - -o /dev/null \
  -H 'Accept-Encoding: gzip' https://example.com/test.txt
Use your own hostname and a safe test file. Inspect Content-Encoding, Vary and HTTP status. To compare raw encoded bytes, save the response body without automatic decompression. curl --compressed instead requests supported compression and decompresses the body, so do not confuse decoded size with wire size.

Our test compared the baseline against removing JPEG/GIF/PNG from gzip_types. It did not change the compression level or worker limits.







  nginx-performance-20261014.jpg (Size: 116.44 KB / Downloads: 4)


AdminsForum formatted transcript of the experiment, not a screenshot.



5. Interpret the evidenceText: gzip was used in both phases; the body transferred was 156 bytes and decoded to 24,500 bytes.


PNG before: gzip body 2,487 bytes, decoded to 3,113 bytes.


PNG after: no gzip; body transferred 3,113 bytes.


All responses returned HTTP 200, and decoded content hashes matched.



Removing image compression increased transfer size for this particular small PNG. We did not measure CPU savings, so we did not claim the change improved performance. These body sizes exclude headers and transport overhead; one file does not represent an entire image library.



6. Validate, reload and restore when appropriate

Code:
/www/server/nginx/sbin/nginx -t
/www/server/nginx/sbin/nginx -s reload
Validation passed for the experiment. Because we had no demonstrated overall benefit, we restored the original configuration, validated it again and reloaded Nginx. A successful reload is not an application test: check important pages, TLS, redirects, upstream errors and logs afterwards.

Do not keep an optimization solely because it looks conventional. Record the tradeoff and test enough representative content to support a decision.



7. Apply this method to a real high-traffic site

Collect response latency, transfer sizes, CPU, connection counts and upstream timing over comparable windows. Separate cached and uncached requests. Change one variable at a time and repeat the same workload. Keep a rollback copy and stop if errors or resource pressure increase.

A compression change cannot repair slow SQL or exhausted PHP workers. Use the database and PHP-FPM guides alongside this test, then investigate the bottleneck actually observed.



Reference: Official Nginx gzip module documentation.


Tune MariaDB Queries in aaPanel with EXPLAIN and Index Tests
Wed, 14 Oct 2026 20:17:01 +0800
A slow website does not automatically need a larger database buffer or more connections. First identify the query, inspect its execution plan and measure a targeted change. This guide demonstrates that workflow in a separate MariaDB lab database.



Tested environment: aaPanel Free 8.0.7, Ubuntu 22.04.5 and MariaDB 10.11.10. MySQL and MariaDB releases differ; verify your installed version before copying configuration advice. We used 50,000 synthetic rows and changed no global database settings.



1. Identify the database and establish a baseline

Open aaPanel → Databases and confirm which service and database the website uses. Inspect application logs and slow queries rather than assuming the homepage represents all workloads. Administrative diagnostics require suitable database permissions; keep credentials out of commands, screenshots and public tutorials.

Code:
SELECT VERSION();
SHOW VARIABLES WHERE Variable_name IN
('innodb_buffer_pool_size','max_connections','slow_query_log','long_query_time');
SHOW GLOBAL STATUS WHERE Variable_name IN
('Threads_connected','Max_used_connections','Innodb_buffer_pool_reads','Innodb_buffer_pool_read_requests');
Our lab had a 384MiB InnoDB buffer pool, max_connections 200, slow logging enabled and a 3-second threshold. Maximum used connections was 3 at that observation. These are observations, not recommended settings for every server.

Counters may accumulate since startup. Take interval snapshots under representative traffic; a one-time cache ratio is not enough to justify allocating more RAM.



2. Find the actual slow query

If slow logging is enabled, review its configured path through an administrator session. Logs can contain query text and user data: keep access restricted and do not upload raw logs to a public thread. A 3-second threshold will miss many shorter queries; choose a diagnostic threshold deliberately and monitor storage overhead.

Find frequently repeated queries as well as individually expensive ones. Record execution count, latency and examined rows. A fast query executed thousands of times may still consume significant resources.



3. Create a separate practice database

Use a disposable database, never a production table, for this example. Our new database was af_performance_index_lab_20261014. In MariaDB 10.11, the sequence table below provides synthetic integers; this syntax is not a portable MySQL recipe.

Code:
CREATE DATABASE af_performance_index_lab_20261014;
USE af_performance_index_lab_20261014;
CREATE TABLE events (
  id INT PRIMARY KEY,
  account_id INT NOT NULL,
  status VARCHAR(16) NOT NULL,
  payload VARCHAR(100) NOT NULL
) ENGINE=InnoDB;
INSERT INTO events
SELECT seq, MOD(seq,1000),
       IF(MOD(seq,2)=0,'active','closed'), REPEAT('x',100)
FROM seq_1_to_50000;
Check that your chosen database name does not already exist. This example creates only synthetic data; adapt names and versions for your own isolated lab.



4. Inspect the query plan before changing anything

Code:
EXPLAIN SELECT SQL_NO_CACHE COUNT(*)
FROM events WHERE account_id=321 AND status='closed';
SQL_NO_CACHE is used here to exclude MariaDB's query-result cache; it does not empty the InnoDB buffer pool. Do not copy this clause into an incompatible database release.

Our plan showed type ALL and an estimated 50,000 rows. EXPLAIN estimates are not measured execution counts, but this plan indicates a full table scan to evaluate the filters.

The query returned 50 matching rows. Record the result so that a faster but incorrect rewrite is not accepted.



5. Test a targeted composite index

Code:
ALTER TABLE events
  ADD INDEX idx_account_status(account_id,status);
ANALYZE TABLE events;
EXPLAIN SELECT SQL_NO_CACHE COUNT(*)
FROM events WHERE account_id=321 AND status='closed';
The new plan used idx_account_status, type ref and an estimated 50 rows. It also reported Using index: this count query can be satisfied from the index entries needed for the filters.

Index design depends on the actual predicates, sorting and joins. Column order matters for other queries using only part of a composite index. Avoid creating an index for every column: indexes use storage and add work to writes.

On a large production table, building an index can consume time, space and locks. Check version-specific online DDL behavior, back up and plan the change before applying it to real data.



6. Compare the same query

We used MariaDB session profiling for this lab: one warmup followed by ten measured executions in each phase. The same database session setting and query were used before and after. Warm data remained possible in the buffer pool; this is not a cold-storage benchmark.

Code:
SET profiling=1;
SELECT SQL_NO_CACHE COUNT(*)
FROM events WHERE account_id=321 AND status='closed';
SHOW PROFILES;
Repeat the SELECT for your sample and inspect its reported duration. Session profiling is version-specific; use the diagnostic tools available in your actual database release. Disable temporary profiling when finished.







  database-index-comparison-20261014.jpg (Size: 115.87 KB / Downloads: 4)


AdminsForum formatted transcript of the original lab test, not a terminal screenshot.



The median of ten measured executions was about 12.72ms before and 0.188ms after. Both phases returned 50 rows. This supports this index for this synthetic query; it does not promise the same improvement for every website or establish production capacity.



7. Tune resources only after reviewing evidence

For InnoDB buffer sizing, account for the working data set and sustained physical reads, while reserving memory for PHP-FPM, Nginx, OS, mail and other services. Dedicated database-server percentage rules are unsuitable for every shared aaPanel VPS.

For max_connections, inspect concurrent connections, application pooling and per-connection memory. Raising the limit can worsen overload. Our observed maximum of 3 did not justify increasing the limit of 200.

Change one setting at a time, retain its original value, validate the database configuration and repeat representative workloads. Monitor swap, OOM events, errors and query latency. A restart can temporarily alter cache warmth and distort comparisons.



8. Verify the website and retain a rollback plan

Test real reads and writes, not just this SELECT. Compare execution plans and results, then monitor normal traffic. For our disposable table, the index can be removed with:

Code:
ALTER TABLE events DROP INDEX idx_account_status;
Do not remove an existing production index without checking its other uses. We retained this isolated lab database and its index for repeatable demonstrations; no application database was modified.



Continue with PHP-FPM memory limits to balance the shared server, rather than tuning each service as though it owns all RAM.





References: MariaDB EXPLAIN and SHOW PROFILES.


Measure PHP OPcache Performance in aaPanel
Wed, 14 Oct 2026 20:14:21 +0800
OPcache stores compiled PHP bytecode so PHP-FPM can reuse it instead of compiling the same scripts for every request. This guide measures that effect on a small WordPress lab and explains how to verify the serving runtime.



Test environment

aaPanel Free 8.0.7, Ubuntu 22.04.5, PHP 8.5.11, Nginx and WordPress. OPcache was already enabled before the experiment. We temporarily disabled it for the comparison and left it enabled afterwards. No production website was used.



1. Confirm the PHP version serving the website

Open Website → your site and inspect its PHP version. Our site used PHP 8.5 through /tmp/php-cgi-85.sock. A command-line PHP result alone cannot prove what PHP-FPM is doing: CLI and FPM may load different configuration files.

Read Check PHP OPcache: CLI vs PHP-FPM first if those results disagree.



2. Back up the active configuration

In App Store → Installed → PHP-8.5 → Setting, inspect the configuration and available extensions. Interface labels depend on the panel release. Confirm the active FPM php.ini before editing; our FPM runtime loaded /www/server/php/85/etc/php.ini, while CLI loaded php-cli.ini.

Keep a backup and working SSH access. A setting change affects the websites sharing that PHP version. Schedule a suitable maintenance window for a busy server.



3. Use a measured starting configuration

Our retained lab settings were:

Code:
[opcache]
opcache.enable=1
opcache.memory_consumption=128
opcache.max_accelerated_files=10000
opcache.validate_timestamps=1
opcache.revalidate_freq=2
The memory value is MiB. The file setting controls the script-cache table size; the actual key capacity may differ from the number configured. Check the runtime rather than assuming they are identical.

Timestamp validation allows changed files to be detected; the revalidation interval controls how frequently checks occur. Disabling validation requires a reliable deployment invalidation process. We kept it enabled and did not change JIT settings.

Do not increase these values merely because traffic increased. Look for cache exhaustion, restarts and the application’s script count, while reserving RAM for other services.



4. Validate and reload the correct pool

Our SSH checks were:

Code:
/www/server/php/85/sbin/php-fpm -t
/etc/init.d/php-fpm-85 reload
Validation passed before each reload. Syntax success does not prove the application works: check important pages and error logs afterwards. Restore the backup and reload if the change causes failures.



5. Verify OPcache through PHP-FPM privately

Our diagnostic script used opcache_get_status(false) and php_ini_loaded_file() through the private Unix socket. It was outside the website root. Passing false excludes the detailed cached-script path listing.

The enabled phase reported FPM SAPI fpm-fcgi, PHP 8.5.11, 532 cached scripts, about 29MiB used and 99MiB free, with zero out-of-memory and hash restarts at that observation. These values describe this small workload, not the needs of every WordPress installation.

Do not publish phpinfo or cache status on an unprotected URL: configuration and paths can disclose server details. Remove temporary diagnostics when finished.



6. Separate page caching from bytecode caching

A full-page cache HIT may avoid PHP entirely. We used unique query strings and verified Nginx-Cache: BYPASS under our existing rules. Query strings do not universally bypass caches; check your own configuration and response headers.

Each phase used 20 warmup requests followed by 20 measured requests at concurrency 2. Requests used loopback HTTPS with normal certificate validation. This isolates much of the network variation but does not represent a remote visitor’s full browser experience.







  opcache-comparison-20261014.jpg (Size: 117.41 KB / Downloads: 4)


AdminsForum formatted transcript of the original experiment, not a terminal screenshot.



7. Interpret the resultsOPcache off: 20/20 HTTP 200; median time to first byte 490ms; small-sample p95 555ms.


OPcache on: 20/20 HTTP 200; median time to first byte 168ms; small-sample p95 190ms.



This workload was faster with OPcache enabled. Twenty requests give limited tail-latency evidence and do not establish maximum visitor capacity. Repeat tests on expensive pages and representative workloads before making production promises.

Runtime hit/miss counters can include warmup and other requests since the cache started; do not treat a cumulative hit ratio as the measured phase alone.



8. Monitor and revisit sizing

Inspect memory used/free/wasted, cached-script count, misses and restart counters over a representative period. An exhausted cache may need additional memory or key capacity; frequent deployments and invalidation also affect results. Check PHP errors and memory pressure alongside cache statistics.

OPcache does not replace SQL indexes, object caching or page caching. Use measured PHP-FPM worker limits to control concurrent process memory separately.



Reference: Official PHP OPcache configuration documentation.