https://adminsforum.com/ Thu, 15 Oct 2026 05:23:39 +0000 MyBB https://adminsforum.com/Thread-guide-fix-primary-script-unknown-php-errors-in-aapanel Thu, 15 Oct 2026 13:05:11 +0800 DEV]]> https://adminsforum.com/Thread-guide-fix-primary-script-unknown-php-errors-in-aapanel If a PHP page returns “File not found” and the Nginx error log says “Primary script unknown,” investigate the script path sent to PHP-FPM. Restarting PHP or raising memory limits does not correct a wrong filename.

This guide follows the request from the website's document root to PHP-FPM. We reproduced a deliberate filename mismatch on a private aaPanel lab endpoint and verified recovery by correcting only that path. Other causes still need evidence from your own logs.


  php-path-20261015.jpg (Size: 124.1 KB / Downloads: 4)
Original AdminsForum lab evidence, presented as a formatted transcript rather than a screenshot.

1. Separate this error from other 404 responses
A missing static image, an application route that does not exist and a PHP script-path error can all produce 404. The status alone cannot distinguish them. Record the exact request path, time and timezone, then check the matching error entry.

In aaPanel open Website → PHP Project, locate the affected site and use Log → Error log. Check the access log for the same request. Labels may differ by panel version. Our lab site's files are:

Code:Copy

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

A short SSH check, using your actual configured domain and log path, is:

Code:Copy

tail -n 100 /www/wwwlogs/example.com.error.log

Do not publish complete logs or configuration dumps; redact private query strings, credentials and customer details.

2. Identify which PHP handler received the request
Our failing error entry included:

Code:Copy

FastCGI sent in stderr: "Primary script unknown" while reading response header from upstream

Its upstream field identified the local PHP 8.5-FPM socket used in our test. Your website may use another PHP version or socket. Confirm the site's selected PHP version and its active configuration instead of copying a socket path from a tutorial.

This message shows that the FastCGI handler responded with a script problem. A connection-refused or missing-socket error points to a different investigation. Do not assume a working command-line PHP binary proves the website uses that same PHP version.

3. Compare the public document root with the deployed files
Open the site's directory settings and inspect the configured website root and, where applicable, its running directory. Then locate the application's intended public entry point in File Manager.

For an illustrative deployment:

Code:Copy

Application directory: /www/wwwroot/example.com/app Public web directory:  /www/wwwroot/example.com/app/public Public entry point:    /www/wwwroot/example.com/app/public/index.php

These are examples, not paths tested on your website. Follow the application's deployment requirements. Do not point the website at a private application directory merely to make an entry file reachable; that can expose configuration or other non-public files.

Check for a moved deployment, wrong folder name, filename case mismatch, missing release or a broken symlink. Linux filenames are case-sensitive. A file you can see in one directory does not prove PHP-FPM is being told to execute that same file.

4. Trace the filename passed to PHP-FPM
In a conventional Nginx root-based PHP setup, a configuration may construct the path like this:

Code:Copy

fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;

For example, a root of /www/wwwroot/example.com/public and a script name of /index.php would form /www/wwwroot/example.com/public/index.php. Inspect the active root, matching location and included PHP configuration together. Alias-based mappings, rewrites and path-info configurations require additional care; the simple example is not a universal replacement.

Do not paste an extra SCRIPT_FILENAME directive on top of the panel's existing PHP include. Find the authoritative setting first. Changing a shared include can affect other websites, so back it up and understand its scope before editing anything.

5. What our isolated test proved
The experiment used Nginx 1.30.5 and the installed PHP 8.5-FPM service. A separate Nginx instance listened only on loopback and accepted one exact test path. It did not alter the real website's routing.

• First, the private configuration sent a deliberately nonexistent script filename to PHP-FPM. The response was 404 with File not found, and the error log recorded Primary script unknown.
  
• Next, we changed only that test filename to an existing, harmless PHP fixture. The response became 200 and contained the expected AdminsForum test message.
  
• The error-log section after correction contained no new matching Primary script unknown error.
  

The disposable PHP file was outside the public website root. It was removed after the test, the private listener was stopped and its PID file disappeared. Hash checks confirmed the main Nginx configuration and PHP-FPM pool configuration were unchanged. The normal HTTPS website returned 200 afterward.

This was a filename-mapping experiment, not a full application repair. It does not prove that your deployment has identical permissions, routing or filesystem restrictions.

6. If the path looks correct, check access and restrictions

• Confirm the target file actually exists at the computed absolute path and that each parent directory can be traversed by the relevant service account.
  
• Check file ownership and read permissions against your deployment's intended accounts. Do not recursively apply 777 permissions or change the ownership of the whole server.
  
• If a pool uses a filesystem jail or other path restrictions, compare the path visible inside that environment. A host-side path may not mean the same thing there.
  
• Look for a specific open_basedir or permission-denied message. Keep the protection enabled while correcting an unintended path or narrowly reviewing the required access.
  
• For framework routes, verify the expected entry point and application rewrite rules separately. A good index.php path does not automatically fix every missing application route.
  

7. Apply the smallest justified correction
Back up the affected website configuration and record the current directory settings. Correct the demonstrated mismatch in the intended site scope. If an application deployment is incomplete, restore the missing release or entry point from the correct source rather than inventing a new index.php.

Validate the complete Nginx configuration before applying a configuration change. If validation fails, restore the backup and investigate the reported line. Do not disable path checks or security controls as a generic repair.

8. Verify both execution and exposure
Request one safe PHP page and confirm its expected content, not just status 200. Check that the error log has no new matching entry. Test an ordinary application route and a static asset, then confirm private application files remain inaccessible through the website.

Remove any temporary diagnostic file you created. Avoid leaving phpinfo pages online. Keep the original configuration backup and record which path changed so you can roll back if another route breaks.

Related guides
Locate website logs in aaPanel
Investigate PHP HTTP 500 errors
Review file permissions and ownership

Technical references
Nginx FastCGI parameter documentation
How Nginx processes requests]]> If a PHP page returns “File not found” and the Nginx error log says “Primary script unknown,” investigate the script path sent to PHP-FPM. Restarting PHP or raising memory limits does not correct a wrong filename.

This guide follows the request from the website's document root to PHP-FPM. We reproduced a deliberate filename mismatch on a private aaPanel lab endpoint and verified recovery by correcting only that path. Other causes still need evidence from your own logs.


  php-path-20261015.jpg (Size: 124.1 KB / Downloads: 4)
Original AdminsForum lab evidence, presented as a formatted transcript rather than a screenshot.

1. Separate this error from other 404 responses
A missing static image, an application route that does not exist and a PHP script-path error can all produce 404. The status alone cannot distinguish them. Record the exact request path, time and timezone, then check the matching error entry.

In aaPanel open Website → PHP Project, locate the affected site and use Log → Error log. Check the access log for the same request. Labels may differ by panel version. Our lab site's files are:

Code:Copy

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

A short SSH check, using your actual configured domain and log path, is:

Code:Copy

tail -n 100 /www/wwwlogs/example.com.error.log

Do not publish complete logs or configuration dumps; redact private query strings, credentials and customer details.

2. Identify which PHP handler received the request
Our failing error entry included:

Code:Copy

FastCGI sent in stderr: "Primary script unknown" while reading response header from upstream

Its upstream field identified the local PHP 8.5-FPM socket used in our test. Your website may use another PHP version or socket. Confirm the site's selected PHP version and its active configuration instead of copying a socket path from a tutorial.

This message shows that the FastCGI handler responded with a script problem. A connection-refused or missing-socket error points to a different investigation. Do not assume a working command-line PHP binary proves the website uses that same PHP version.

3. Compare the public document root with the deployed files
Open the site's directory settings and inspect the configured website root and, where applicable, its running directory. Then locate the application's intended public entry point in File Manager.

For an illustrative deployment:

Code:Copy

Application directory: /www/wwwroot/example.com/app Public web directory:  /www/wwwroot/example.com/app/public Public entry point:    /www/wwwroot/example.com/app/public/index.php

These are examples, not paths tested on your website. Follow the application's deployment requirements. Do not point the website at a private application directory merely to make an entry file reachable; that can expose configuration or other non-public files.

Check for a moved deployment, wrong folder name, filename case mismatch, missing release or a broken symlink. Linux filenames are case-sensitive. A file you can see in one directory does not prove PHP-FPM is being told to execute that same file.

4. Trace the filename passed to PHP-FPM
In a conventional Nginx root-based PHP setup, a configuration may construct the path like this:

Code:Copy

fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;

For example, a root of /www/wwwroot/example.com/public and a script name of /index.php would form /www/wwwroot/example.com/public/index.php. Inspect the active root, matching location and included PHP configuration together. Alias-based mappings, rewrites and path-info configurations require additional care; the simple example is not a universal replacement.

Do not paste an extra SCRIPT_FILENAME directive on top of the panel's existing PHP include. Find the authoritative setting first. Changing a shared include can affect other websites, so back it up and understand its scope before editing anything.

5. What our isolated test proved
The experiment used Nginx 1.30.5 and the installed PHP 8.5-FPM service. A separate Nginx instance listened only on loopback and accepted one exact test path. It did not alter the real website's routing.

• First, the private configuration sent a deliberately nonexistent script filename to PHP-FPM. The response was 404 with File not found, and the error log recorded Primary script unknown.
  
• Next, we changed only that test filename to an existing, harmless PHP fixture. The response became 200 and contained the expected AdminsForum test message.
  
• The error-log section after correction contained no new matching Primary script unknown error.
  

The disposable PHP file was outside the public website root. It was removed after the test, the private listener was stopped and its PID file disappeared. Hash checks confirmed the main Nginx configuration and PHP-FPM pool configuration were unchanged. The normal HTTPS website returned 200 afterward.

This was a filename-mapping experiment, not a full application repair. It does not prove that your deployment has identical permissions, routing or filesystem restrictions.

6. If the path looks correct, check access and restrictions

• Confirm the target file actually exists at the computed absolute path and that each parent directory can be traversed by the relevant service account.
  
• Check file ownership and read permissions against your deployment's intended accounts. Do not recursively apply 777 permissions or change the ownership of the whole server.
  
• If a pool uses a filesystem jail or other path restrictions, compare the path visible inside that environment. A host-side path may not mean the same thing there.
  
• Look for a specific open_basedir or permission-denied message. Keep the protection enabled while correcting an unintended path or narrowly reviewing the required access.
  
• For framework routes, verify the expected entry point and application rewrite rules separately. A good index.php path does not automatically fix every missing application route.
  

7. Apply the smallest justified correction
Back up the affected website configuration and record the current directory settings. Correct the demonstrated mismatch in the intended site scope. If an application deployment is incomplete, restore the missing release or entry point from the correct source rather than inventing a new index.php.

Validate the complete Nginx configuration before applying a configuration change. If validation fails, restore the backup and investigate the reported line. Do not disable path checks or security controls as a generic repair.

8. Verify both execution and exposure
Request one safe PHP page and confirm its expected content, not just status 200. Check that the error log has no new matching entry. Test an ordinary application route and a static asset, then confirm private application files remain inaccessible through the website.

Remove any temporary diagnostic file you created. Avoid leaving phpinfo pages online. Keep the original configuration backup and record which path changed so you can roll back if another route breaks.

Related guides
Locate website logs in aaPanel
Investigate PHP HTTP 500 errors
Review file permissions and ownership

Technical references
Nginx FastCGI parameter documentation
How Nginx processes requests]]> https://adminsforum.com/Thread-guide-fix-429-too-many-requests-errors-in-aapanel Thu, 15 Oct 2026 12:42:27 +0800 DEV]]> https://adminsforum.com/Thread-guide-fix-429-too-many-requests-errors-in-aapanel A 429 Too Many Requests response usually means a request limit has been reached. Find the layer issuing the response before changing a setting: it may be your CDN, Nginx, a security plugin or the application itself.

This guide demonstrates one Nginx limiter on a private lab endpoint. It does not assume every aaPanel website has that rule, and it does not recommend turning off protection to make an error disappear.


  nginx-429-20261015.jpg (Size: 116.42 KB / Downloads: 4)
Original AdminsForum lab results, formatted as a transcript rather than a screenshot.

1. Capture one safe example
Record the URL path, time and timezone, action, response status and how often the client is sending requests. Does it affect everyone, one network, one account or only a particular API? A page can send many background requests even when a user clicks once.

Inspect response headers in your browser's Network tab. If a Retry-After header is present, use its stated delay; do not assume every limiter supplies it. Avoid repeatedly submitting login forms, purchases or imports while diagnosing the problem. Save a redacted error example without session cookies, authorization headers or private query strings.

2. Match the response to website logs
In aaPanel open Website → PHP Project, find the affected site and select Log. Check Access log and Error log around the recorded time. Refresh and expand the displayed line count if needed. Labels may vary by panel version.

Our lab site's logs are at:

Code:Copy

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

Use the actual path configured for your own domain. A bounded SSH check is:

Code:Copy

tail -n 100 /www/wwwlogs/example.com.log tail -n 100 /www/wwwlogs/example.com.error.log

A 429 entry confirms that this log recorded the response, but does not by itself identify the rule. If there is no matching origin request, check the CDN or earlier proxy's events and verify you selected the correct log. Application-generated 429 responses need application logs too.

3. Recognize an Nginx rate-limit rejection
Our test error log contained:

Code:Copy

limiting requests, excess: 0.991 by zone "af429"

The named zone was our own test limiter. Its name is not a built-in aaPanel setting. We also added a diagnostic access-log field in the isolated configuration and saw:

Code:Copy

200 PASSED 429 REJECTED 200 PASSED

Default website logs may not contain that extra field. Do not expect to find it unless your log format includes it. Nginx can use a different rejection status; seeing 503 instead of 429 does not rule out a request limiter.

4. What the private experiment tested
We ran a separate Nginx configuration listening only on the lab's loopback interface. One exact path served a harmless text fixture. Its illustrative limit allowed one request per second with no extra burst allowance, and we explicitly selected 429 for rejections.

• The first request returned 200 with the expected text.
  
• An immediate second request returned 429, with a matching limiter rejection in the error log.
  
• After a 1.2-second pause, the next request returned 200 with the same expected text.
  

The limiter stayed active throughout. Only three requests were measured in this corrected run; this was not a load test or an application-capacity benchmark. An earlier fixture path had a permissions error, which was corrected separately before this comparison. Waiting cleared this synthetic rate condition; it does not prove waiting fixes every real 429.

The temporary listener was stopped and its PID file and disposable text fixture were removed. The main Nginx configuration hash remained unchanged, and the normal HTTPS website returned 200 afterward.

5. Fix the cause at the correct layer

• A client is polling too frequently: reduce unnecessary refreshes, use caching where appropriate and apply bounded backoff. Honor Retry-After when supplied. Do not create a rapid retry loop after a rejection.
  
• An application account or API quota is reached: inspect that service's quota and application logs. Changing Nginx cannot increase a third-party API allowance. Check for duplicate jobs or repeated failed requests.
  
• A CDN or WAF rule is rejecting legitimate traffic: inspect the matching event and rule. Consider a narrow, documented adjustment for the intended endpoint after reviewing the evidence. Keep login and abuse protections in place.
  
• Nginx sees many visitors as one address: investigate how the trusted reverse proxy communicates client addresses. This is a configuration review, not a reason to trust arbitrary forwarded headers. Incorrect trust settings can let clients spoof identities.
  
• A valid origin rule is too strict for an application's normal behavior: measure that endpoint's legitimate request pattern before choosing a scoped allowance. Avoid a blanket site-wide exemption or unlimited burst setting.
  

6. Review configuration safely
Before editing, back up the affected site's configuration and identify any included rules. Note the rule scope, key, rate and burst behavior. The test's one-request-per-second allowance was deliberately restrictive and is not a recommended value for your site.

If you have evidence for a change, alter only the intended rule, validate the complete Nginx configuration using the panel's validation mechanism and apply it only after validation passes. Keep the previous configuration for rollback. Do not add duplicate location blocks or globally disable a security plugin to fix one URL.

7. Verify without creating more traffic problems
Repeat a small number of safe requests at a normal pace. Check both response content and status, then inspect the corresponding logs. Confirm that ordinary users can finish the intended action and that the relevant protection still applies to excessive requests in a controlled test environment.

Do not run bursts against a production login or somebody else's API. If many visitors share a corporate or mobile network, include that scenario in your review. Observe a representative period before calling an intermittent issue resolved.

When asking for help, include
The failing path without private query data, time and timezone, which layer logged the rejection, a short redacted log excerpt, approximate request frequency and any recent rule changes. Never include authentication headers, full session cookies or API keys.

Related guides
Find website access and error logs in aaPanel
Monitor resource use during controlled traffic tests

Technical reference
Official Nginx request-limit module documentation]]> A 429 Too Many Requests response usually means a request limit has been reached. Find the layer issuing the response before changing a setting: it may be your CDN, Nginx, a security plugin or the application itself.

This guide demonstrates one Nginx limiter on a private lab endpoint. It does not assume every aaPanel website has that rule, and it does not recommend turning off protection to make an error disappear.


  nginx-429-20261015.jpg (Size: 116.42 KB / Downloads: 4)
Original AdminsForum lab results, formatted as a transcript rather than a screenshot.

1. Capture one safe example
Record the URL path, time and timezone, action, response status and how often the client is sending requests. Does it affect everyone, one network, one account or only a particular API? A page can send many background requests even when a user clicks once.

Inspect response headers in your browser's Network tab. If a Retry-After header is present, use its stated delay; do not assume every limiter supplies it. Avoid repeatedly submitting login forms, purchases or imports while diagnosing the problem. Save a redacted error example without session cookies, authorization headers or private query strings.

2. Match the response to website logs
In aaPanel open Website → PHP Project, find the affected site and select Log. Check Access log and Error log around the recorded time. Refresh and expand the displayed line count if needed. Labels may vary by panel version.

Our lab site's logs are at:

Code:Copy

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

Use the actual path configured for your own domain. A bounded SSH check is:

Code:Copy

tail -n 100 /www/wwwlogs/example.com.log tail -n 100 /www/wwwlogs/example.com.error.log

A 429 entry confirms that this log recorded the response, but does not by itself identify the rule. If there is no matching origin request, check the CDN or earlier proxy's events and verify you selected the correct log. Application-generated 429 responses need application logs too.

3. Recognize an Nginx rate-limit rejection
Our test error log contained:

Code:Copy

limiting requests, excess: 0.991 by zone "af429"

The named zone was our own test limiter. Its name is not a built-in aaPanel setting. We also added a diagnostic access-log field in the isolated configuration and saw:

Code:Copy

200 PASSED 429 REJECTED 200 PASSED

Default website logs may not contain that extra field. Do not expect to find it unless your log format includes it. Nginx can use a different rejection status; seeing 503 instead of 429 does not rule out a request limiter.

4. What the private experiment tested
We ran a separate Nginx configuration listening only on the lab's loopback interface. One exact path served a harmless text fixture. Its illustrative limit allowed one request per second with no extra burst allowance, and we explicitly selected 429 for rejections.

• The first request returned 200 with the expected text.
  
• An immediate second request returned 429, with a matching limiter rejection in the error log.
  
• After a 1.2-second pause, the next request returned 200 with the same expected text.
  

The limiter stayed active throughout. Only three requests were measured in this corrected run; this was not a load test or an application-capacity benchmark. An earlier fixture path had a permissions error, which was corrected separately before this comparison. Waiting cleared this synthetic rate condition; it does not prove waiting fixes every real 429.

The temporary listener was stopped and its PID file and disposable text fixture were removed. The main Nginx configuration hash remained unchanged, and the normal HTTPS website returned 200 afterward.

5. Fix the cause at the correct layer

• A client is polling too frequently: reduce unnecessary refreshes, use caching where appropriate and apply bounded backoff. Honor Retry-After when supplied. Do not create a rapid retry loop after a rejection.
  
• An application account or API quota is reached: inspect that service's quota and application logs. Changing Nginx cannot increase a third-party API allowance. Check for duplicate jobs or repeated failed requests.
  
• A CDN or WAF rule is rejecting legitimate traffic: inspect the matching event and rule. Consider a narrow, documented adjustment for the intended endpoint after reviewing the evidence. Keep login and abuse protections in place.
  
• Nginx sees many visitors as one address: investigate how the trusted reverse proxy communicates client addresses. This is a configuration review, not a reason to trust arbitrary forwarded headers. Incorrect trust settings can let clients spoof identities.
  
• A valid origin rule is too strict for an application's normal behavior: measure that endpoint's legitimate request pattern before choosing a scoped allowance. Avoid a blanket site-wide exemption or unlimited burst setting.
  

6. Review configuration safely
Before editing, back up the affected site's configuration and identify any included rules. Note the rule scope, key, rate and burst behavior. The test's one-request-per-second allowance was deliberately restrictive and is not a recommended value for your site.

If you have evidence for a change, alter only the intended rule, validate the complete Nginx configuration using the panel's validation mechanism and apply it only after validation passes. Keep the previous configuration for rollback. Do not add duplicate location blocks or globally disable a security plugin to fix one URL.

7. Verify without creating more traffic problems
Repeat a small number of safe requests at a normal pace. Check both response content and status, then inspect the corresponding logs. Confirm that ordinary users can finish the intended action and that the relevant protection still applies to excessive requests in a controlled test environment.

Do not run bursts against a production login or somebody else's API. If many visitors share a corporate or mobile network, include that scenario in your review. Observe a representative period before calling an intermittent issue resolved.

When asking for help, include
The failing path without private query data, time and timezone, which layer logged the rejection, a short redacted log excerpt, approximate request frequency and any recent rule changes. Never include authentication headers, full session cookies or API keys.

Related guides
Find website access and error logs in aaPanel
Monitor resource use during controlled traffic tests

Technical reference
Official Nginx request-limit module documentation]]> https://adminsforum.com/Thread-guide-fix-504-gateway-timeout-errors-in-aapanel-using-logs Thu, 15 Oct 2026 12:24:18 +0800 DEV]]> https://adminsforum.com/Thread-guide-fix-504-gateway-timeout-errors-in-aapanel-using-logs A 504 Gateway Timeout means a gateway did not receive a timely response from its upstream. The useful next step is to identify which gateway timed out and what it was waiting for. A slow SQL query, external API, busy PHP worker pool or an unreachable upstream can require very different fixes.

This guide uses an isolated Nginx HTTP-proxy experiment, then shows how to investigate a real aaPanel website. The tested values below are deliberately tiny lab settings, not recommended production limits.


  nginx-504-20261015.jpg (Size: 130.65 KB / Downloads: 4)
AdminsForum original lab results, presented as a formatted transcript rather than a screenshot.

1. Record the failing request before changing settings
Write down the exact time and timezone, domain, path, action and approximate waiting time. Does one report page fail, or every page? Does it fail only during traffic peaks? Avoid repeatedly submitting payments, imports or other actions that might continue on the server after the browser gives up.

Check whether the response comes from your origin Nginx, another reverse proxy or a CDN. A branded error page is a clue, not conclusive proof of which layer caused the delay. Match the request against origin logs. Do not disable your firewall or expose a private origin to diagnose this.

2. Find the matching website logs in aaPanel
Open Website → PHP Project, locate the affected site and use its Log control. Inspect Access log and Error log around the recorded time. Refresh the viewer and expand the displayed line count if necessary. Panel layouts differ by version.

On our lab site the files are:

Code:Copy

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

Replace the domain with your own site's actual configured log path. A bounded SSH check is:

Code:Copy

tail -n 100 /www/wwwlogs/example.com.error.log tail -n 100 /www/wwwlogs/example.com.log

Do not paste complete logs publicly: redact tokens, private query strings, addresses and customer information. A browser 504 with no matching origin request may point to an earlier proxy layer or the wrong log file.

3. Read the upstream error, not just the status code
Our failing request produced this shortened error:

Code:Copy

upstream timed out (110: Connection timed out) while reading response header from upstream

Here Nginx was waiting for the upstream response header. A message about connecting to the upstream points to a different phase: check the upstream address, listener, route and service health. A connection refusal often leads to 502 instead; do not treat every gateway failure as the same problem.

The error line's upstream field helps distinguish HTTP proxying from FastCGI. Correlate the path and timestamp with the application log and, for PHP, its slow log. A 504 alone does not prove that MySQL, PHP or Nginx needs a larger limit.

4. Understand the two common read-timeout settings

Code:Copy

# HTTP reverse proxy: Node, Python or another HTTP service proxy_read_timeout 30s; # FastCGI: commonly a PHP-FPM website fastcgi_read_timeout 30s;

These are illustrative directives, not instructions to add both. Identify the active location and included configuration first. Do not create a second conflicting location block or edit a shared PHP include without understanding every affected site.

Nginx read timeouts measure the allowed gap between successive reads from the upstream; they are not a universal total request duration limit. Connection timeouts govern another phase. PHP execution limits, PHP-FPM termination limits and CDN or load-balancer limits are separate and may end the request sooner.

5. What our isolated test actually demonstrated
The lab used the installed Nginx 1.30.5 binary, a separate configuration and two loopback-only listeners. Its dummy HTTP upstream deliberately waited before returning a response. There were only three measured requests:

• Delay 2 seconds, read timeout 1 second: 504 in 1.002187 seconds, with an upstream-header timeout in the error log.
  
• Same 2-second delay, read timeout 4 seconds: 200 in 2.002012 seconds. The longer allowance did not make the upstream faster.
  
• Artificial delay reduced to 0.2 seconds, original 1-second timeout restored: 200 in 0.202015 seconds.
  

The last phase changed a synthetic sleep, not a real database query or production application. This demonstrates timeout behavior, not PHP capacity or a universal performance improvement. Both test listeners were closed, the isolated PID file disappeared, the main Nginx configuration hash stayed unchanged and the normal HTTPS site returned 200 afterward.

6. Investigate what the real application is waiting for

• Slow PHP code: correlate a PHP-FPM slow-log stack with the failing URL. Check whether workers are busy or requests are queuing. Raising worker counts beyond available memory can make the situation worse.
  
• Database work: identify the actual slow query and inspect its plan before adding an index. Check locks and transaction duration. Do not change global database limits based on one gateway error.
  
• External API: inspect the application's outgoing request timeout and upstream provider status. Use bounded retries and a clear failure response; retries can multiply load.
  
• Traffic or resource pressure: compare CPU, available memory, swap activity and disk latency with the incident time. A quiet server after the event does not rule out an earlier spike.
  
• Long exports or imports: consider a background job with status polling and a downloadable result. Increasing web timeouts indefinitely leaves connections and workers occupied.
  

7. If a timeout adjustment is justified, make it deliberately
Back up the affected site's configuration. Record the old value, the expected operation duration and the limits of every proxy in front of it. In aaPanel open the affected site's configuration and locate the active proxy or FastCGI section. Change only the appropriate directive in the intended scope, then run the panel's configuration validation before applying or reloading it. Restore the backup if validation fails.

Do not copy the lab's 1-second or 4-second settings to your website. Choose a finite budget based on a legitimate request and measured behavior. A larger budget is sometimes appropriate, but it also permits longer resource occupancy and does not repair slow application work.

8. Verify the result and keep a rollback path
Repeat one safe request and compare status, response content and elapsed time. Check the application actually finished; an HTTP 200 alone can contain an application error. Confirm the error log has no new matching upstream timeout, inspect nearby normal pages and monitor resource use. For an intermittent issue, observe a representative traffic period before declaring it fixed.

A simple non-mutating request timing example is:

Code:Copy

curl -sS --max-time 45 -o /dev/null \   -w 'HTTP %{http_code} | total %{time_total}s\n' \   https://example.com/safe-status-page

Use a real, safe URL on your site. curl's own maximum time is a client-side limit, separate from Nginx's upstream timeout. Never include login tokens or secrets in a public command example.

Related troubleshooting guides
Find website access and error logs in aaPanel
Trace slow PHP requests with PHP-FPM slow logs
Investigate MariaDB query plans and indexes

Technical references
Nginx proxy_read_timeout documentation
Nginx fastcgi_read_timeout documentation]]> A 504 Gateway Timeout means a gateway did not receive a timely response from its upstream. The useful next step is to identify which gateway timed out and what it was waiting for. A slow SQL query, external API, busy PHP worker pool or an unreachable upstream can require very different fixes.

This guide uses an isolated Nginx HTTP-proxy experiment, then shows how to investigate a real aaPanel website. The tested values below are deliberately tiny lab settings, not recommended production limits.


  nginx-504-20261015.jpg (Size: 130.65 KB / Downloads: 4)
AdminsForum original lab results, presented as a formatted transcript rather than a screenshot.

1. Record the failing request before changing settings
Write down the exact time and timezone, domain, path, action and approximate waiting time. Does one report page fail, or every page? Does it fail only during traffic peaks? Avoid repeatedly submitting payments, imports or other actions that might continue on the server after the browser gives up.

Check whether the response comes from your origin Nginx, another reverse proxy or a CDN. A branded error page is a clue, not conclusive proof of which layer caused the delay. Match the request against origin logs. Do not disable your firewall or expose a private origin to diagnose this.

2. Find the matching website logs in aaPanel
Open Website → PHP Project, locate the affected site and use its Log control. Inspect Access log and Error log around the recorded time. Refresh the viewer and expand the displayed line count if necessary. Panel layouts differ by version.

On our lab site the files are:

Code:Copy

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

Replace the domain with your own site's actual configured log path. A bounded SSH check is:

Code:Copy

tail -n 100 /www/wwwlogs/example.com.error.log tail -n 100 /www/wwwlogs/example.com.log

Do not paste complete logs publicly: redact tokens, private query strings, addresses and customer information. A browser 504 with no matching origin request may point to an earlier proxy layer or the wrong log file.

3. Read the upstream error, not just the status code
Our failing request produced this shortened error:

Code:Copy

upstream timed out (110: Connection timed out) while reading response header from upstream

Here Nginx was waiting for the upstream response header. A message about connecting to the upstream points to a different phase: check the upstream address, listener, route and service health. A connection refusal often leads to 502 instead; do not treat every gateway failure as the same problem.

The error line's upstream field helps distinguish HTTP proxying from FastCGI. Correlate the path and timestamp with the application log and, for PHP, its slow log. A 504 alone does not prove that MySQL, PHP or Nginx needs a larger limit.

4. Understand the two common read-timeout settings

Code:Copy

# HTTP reverse proxy: Node, Python or another HTTP service proxy_read_timeout 30s; # FastCGI: commonly a PHP-FPM website fastcgi_read_timeout 30s;

These are illustrative directives, not instructions to add both. Identify the active location and included configuration first. Do not create a second conflicting location block or edit a shared PHP include without understanding every affected site.

Nginx read timeouts measure the allowed gap between successive reads from the upstream; they are not a universal total request duration limit. Connection timeouts govern another phase. PHP execution limits, PHP-FPM termination limits and CDN or load-balancer limits are separate and may end the request sooner.

5. What our isolated test actually demonstrated
The lab used the installed Nginx 1.30.5 binary, a separate configuration and two loopback-only listeners. Its dummy HTTP upstream deliberately waited before returning a response. There were only three measured requests:

• Delay 2 seconds, read timeout 1 second: 504 in 1.002187 seconds, with an upstream-header timeout in the error log.
  
• Same 2-second delay, read timeout 4 seconds: 200 in 2.002012 seconds. The longer allowance did not make the upstream faster.
  
• Artificial delay reduced to 0.2 seconds, original 1-second timeout restored: 200 in 0.202015 seconds.
  

The last phase changed a synthetic sleep, not a real database query or production application. This demonstrates timeout behavior, not PHP capacity or a universal performance improvement. Both test listeners were closed, the isolated PID file disappeared, the main Nginx configuration hash stayed unchanged and the normal HTTPS site returned 200 afterward.

6. Investigate what the real application is waiting for

• Slow PHP code: correlate a PHP-FPM slow-log stack with the failing URL. Check whether workers are busy or requests are queuing. Raising worker counts beyond available memory can make the situation worse.
  
• Database work: identify the actual slow query and inspect its plan before adding an index. Check locks and transaction duration. Do not change global database limits based on one gateway error.
  
• External API: inspect the application's outgoing request timeout and upstream provider status. Use bounded retries and a clear failure response; retries can multiply load.
  
• Traffic or resource pressure: compare CPU, available memory, swap activity and disk latency with the incident time. A quiet server after the event does not rule out an earlier spike.
  
• Long exports or imports: consider a background job with status polling and a downloadable result. Increasing web timeouts indefinitely leaves connections and workers occupied.
  

7. If a timeout adjustment is justified, make it deliberately
Back up the affected site's configuration. Record the old value, the expected operation duration and the limits of every proxy in front of it. In aaPanel open the affected site's configuration and locate the active proxy or FastCGI section. Change only the appropriate directive in the intended scope, then run the panel's configuration validation before applying or reloading it. Restore the backup if validation fails.

Do not copy the lab's 1-second or 4-second settings to your website. Choose a finite budget based on a legitimate request and measured behavior. A larger budget is sometimes appropriate, but it also permits longer resource occupancy and does not repair slow application work.

8. Verify the result and keep a rollback path
Repeat one safe request and compare status, response content and elapsed time. Check the application actually finished; an HTTP 200 alone can contain an application error. Confirm the error log has no new matching upstream timeout, inspect nearby normal pages and monitor resource use. For an intermittent issue, observe a representative traffic period before declaring it fixed.

A simple non-mutating request timing example is:

Code:Copy

curl -sS --max-time 45 -o /dev/null \   -w 'HTTP %{http_code} | total %{time_total}s\n' \   https://example.com/safe-status-page

Use a real, safe URL on your site. curl's own maximum time is a client-side limit, separate from Nginx's upstream timeout. Never include login tokens or secrets in a public command example.

Related troubleshooting guides
Find website access and error logs in aaPanel
Trace slow PHP requests with PHP-FPM slow logs
Investigate MariaDB query plans and indexes

Technical references
Nginx proxy_read_timeout documentation
Nginx fastcgi_read_timeout documentation]]> https://adminsforum.com/Thread-guide-fix-413-request-entity-too-large-errors-in-aapanel Thu, 15 Oct 2026 11:34:38 +0800 DEV]]> https://adminsforum.com/Thread-guide-fix-413-request-entity-too-large-errors-in-aapanel 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:Copy

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:Copy

client_max_body_size 1k;

Nginx returned 413. We changed only that test limit to:

Code:Copy

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: 6)
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:Copy

/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:Copy

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:Copy

/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.]]> 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:Copy

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:Copy

client_max_body_size 1k;

Nginx returned 413. We changed only that test limit to:

Code:Copy

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: 6)
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:Copy

/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:Copy

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:Copy

/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.]]> https://adminsforum.com/Thread-guide-fix-403-forbidden-errors-in-aapanel-using-logs Wed, 14 Oct 2026 21:18:55 +0800 DEV]]> https://adminsforum.com/Thread-guide-fix-403-forbidden-errors-in-aapanel-using-logs 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:Copy

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:Copy

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:Copy

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:Copy

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:Copy

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: 7)
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.]]> 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:Copy

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:Copy

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:Copy

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:Copy

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:Copy

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: 7)
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.]]> https://adminsforum.com/Thread-guide-fix-php-http-500-errors-in-aapanel-using-error-logs Wed, 14 Oct 2026 21:11:00 +0800 DEV]]> https://adminsforum.com/Thread-guide-fix-php-http-500-errors-in-aapanel-using-error-logs 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:Copy

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:Copy

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: 8)
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:Copy

/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.]]> 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:Copy

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:Copy

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: 8)
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:Copy

/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.]]> https://adminsforum.com/Thread-guide-cloudpanel-backups-and-security-remote-backups-firewall-and-basic-auth Wed, 14 Oct 2026 21:10:47 +0800 JAY]]> https://adminsforum.com/Thread-guide-cloudpanel-backups-and-security-remote-backups-firewall-and-basic-auth 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: 6)

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: 6)

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: 6)

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: 6)

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: 6)

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:Copy

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: 6)

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: 6)

• 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: 6)

Part 5: Keep everything updated

Code:Copy

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

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

]]> 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: 6)

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: 6)

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: 6)

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: 6)

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: 6)

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:Copy

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: 6)

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: 6)

• 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: 6)

Part 5: Keep everything updated

Code:Copy

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

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

]]> https://adminsforum.com/Thread-guide-cloudpanel-cron-jobs-logs-and-varnish-cache-complete-guide Wed, 14 Oct 2026 21:10:14 +0800 JAY]]> https://adminsforum.com/Thread-guide-cloudpanel-cron-jobs-logs-and-varnish-cache-complete-guide 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: 5)

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:Copy

  */5 * * * *
  )
  
• Command:
  
  Code:Copy

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

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

Then add this line to wp-config.php so WordPress doesn't also run it on page loads:

Code:Copy

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: 5)

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: 5)

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: 5)

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

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

]]> 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: 5)

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:Copy

  */5 * * * *
  )
  
• Command:
  
  Code:Copy

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

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

Then add this line to wp-config.php so WordPress doesn't also run it on page loads:

Code:Copy

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: 5)

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: 5)

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: 5)

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

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

]]> https://adminsforum.com/Thread-guide-cloudpanel-ssh-sftp-ftp-and-file-manager-how-to-upload-files Wed, 14 Oct 2026 21:09:43 +0800 JAY]]> https://adminsforum.com/Thread-guide-cloudpanel-ssh-sftp-ftp-and-file-manager-how-to-upload-files 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: 6)

2. Log in over SSH
From your own computer:

Code:Copy

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:Copy

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: 6)

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: 6)

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

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

]]> 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: 6)

2. Log in over SSH
From your own computer:

Code:Copy

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:Copy

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: 6)

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: 6)

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

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

]]> https://adminsforum.com/Thread-guide-cloudpanel-databases-create-a-database-users-and-use-phpmyadmin Wed, 14 Oct 2026 21:09:13 +0800 JAY]]> https://adminsforum.com/Thread-guide-cloudpanel-databases-create-a-database-users-and-use-phpmyadmin 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: 6)

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: 6)

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: 6)

Step 5: Big imports and exports with clpctl
Large databases can time out in the browser. As root, use clpctl instead:

Code:Copy

# 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: 6)

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

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

]]> 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: 6)

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: 6)

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: 6)

Step 5: Big imports and exports with clpctl
Large databases can time out in the browser. As root, use clpctl instead:

Code:Copy

# 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: 6)

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

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

]]>