https://adminsforum.com/ Thu, 15 Oct 2026 05:22:24 +0000 MyBB 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-monitor-server-resources-during-aapanel-website-traffic-tests Wed, 14 Oct 2026 20:51:09 +0800 DEV]]> https://adminsforum.com/Thread-guide-monitor-server-resources-during-aapanel-website-traffic-tests Response times tell you that a site slowed down; simultaneous server measurements help explain why. This guide pairs a bounded WordPress traffic test with CPU, memory, swap and I/O observations on an aaPanel lab VPS.

Test environment: aaPanel Free 8.0.7, Ubuntu 22.04.5, two virtual CPUs and about 3.8GiB RAM, with Nginx, WordPress and PHP 8.5. The server also runs database, mail and other lab services. A separate Windows client generated traffic. We changed no server settings for this run.

1. Define the question before generating traffic
Are slow responses accompanied by CPU activity, memory pressure, storage waiting or application queueing? Choose a harmless lab endpoint and collect a baseline. Do not test destructive application actions or run an unlimited traffic loop.
Our test used the WordPress homepage with unique query strings. The existing FastCGI rules bypass query-string requests, verified in the earlier cache guide. A cached anonymous homepage could hide the PHP work we wanted to observe.
Start with the controlled load-test guide for request limits, TLS checks and timing definitions. This follow-up adds simultaneous resource evidence rather than repeating a capacity claim.

2. Capture memory and load snapshots
On the lab server, use a private SSH session:

Code:Copy

date -Is uptime free -h cat /proc/meminfo

Record the clock and timezone. The client and server must have reasonably aligned clocks to correlate events. Low free memory alone does not demonstrate a problem; include available memory and swap activity. A load average is also not a direct CPU percentage.
Our MemAvailable snapshots were 2,849,192KiB before and 2,813,252KiB after, approximately 2.72GiB and 2.68GiB. These are two snapshots, not the minimum available memory throughout the run.

3. Start a finite interval sampler
Our existing vmstat utility required no additional package installation. We ran:

Code:Copy

LC_ALL=C vmstat -n -t 1 25

This requests one-second updates and a finite count. Keep the output in a private administration session or log, and note the sampler's start/end time. It should overlap the request phases, not run only after the workload finishes.
The first data row includes activity averages since boot. We excluded it from interval summaries. Process and memory columns are snapshots; later activity columns cover the sampling interval. In this run we retained 24 interval rows across the traffic and surrounding idle time.

4. Understand the useful columns

• r: runnable work; compare repeated values with the CPU count, not one isolated spike.
  
• b: work blocked waiting for I/O completion.
  
• us and sy: user and kernel CPU percentages. Our CPU activity summary used 100 minus idle, I/O wait and steal.
  
• id, wa and st: idle, I/O-wait and virtual-machine steal percentages; these describe different conditions.
  
• si and so: swap-in and swap-out activity. Existing swap usage without current transfers is different from sustained swapping.
  
• bi and bo: block input/output activity. These alone do not identify which disk or application is responsible.
  

Check the local manual for units and version details. Small one-second samples can hide shorter spikes, while whole-server measurements combine activity from every service.

5. Run a bounded client workload
We used 80 requests at concurrency 4, followed by 80 at concurrency 8. Every request used HTTPS with normal certificate validation, a 15-second maximum time and no retry. The run would stop before a later phase if any request failed or its sample p95 TTFB exceeded five seconds.
The generator ran off the VPS, so its local client work did not consume the VPS CPUs being measured. It used a finite worker pool: after one request completed, a worker could submit another. This closed-loop workload does not reproduce every real traffic pattern.
Keep important service health under observation and stop if your lab becomes unstable. Do not increase concurrency just to force a failure.

6. Compare the recorded results

  monitor-load-20261014.jpg (Size: 128.09 KB / Downloads: 9)
AdminsForum formatted transcript of the original measurements, not a terminal screenshot.

• Concurrency 4: 80/80 HTTP 200, median TTFB 313ms, sample p95 467ms, elapsed phase about 10.20 seconds.
  
• Concurrency 8: 80/80 HTTP 200, median TTFB 414ms, sample p95 539ms, elapsed phase about 5.76 seconds.
  
• Across the 24 resource intervals: CPU activity peaked at 88%, I/O wait at 0%, steal at 1%, and runnable work at 6.
  
• Every interval reported zero swap-in and zero swap-out; available-memory snapshots remained about 2.7GiB.
  

The higher-concurrency phase completed its finite batch sooner but had higher median latency. These short phases were not repeated in randomized order, and other lab services may contribute to whole-server CPU activity.
The resource summary includes idle time around the test. Its peak values should not be confused with a phase average. We did not measure FPM queue lengths, individual query timing, per-process CPU attribution or device latency in this run.

7. Form a hypothesis without overstating it
The observations do not show sampled swap pressure or I/O-wait activity. CPU work is a plausible next investigation because activity increased during this request workload. They do not prove that CPU is the only bottleneck or that the VPS can sustain this traffic indefinitely.
For a stronger diagnosis, correlate process CPU, private FPM queue/status observations and application timings with the same request timestamps. Read the PHP slow-log guide to locate executing requests and the database index guide when SQL is implicated.
If storage is suspected, collect device-level latency and queue information as a separate test. A sampled wa value of zero is not proof that every storage operation was instantaneous.

8. Choose the next change from evidence
CPU-heavy PHP work may benefit from application improvements or appropriate caching; adding workers can increase contention. Memory pressure calls for examining actual process use and service budgets. Slow SQL calls for a query plan, not an arbitrary increase to max_connections.
Change one variable, retain a rollback copy and repeat the same workload with the sampler running. Check content correctness and errors as well as speed. HTTP 200 alone cannot establish that an application returned the intended page.

9. Keep the test reproducible
Save phase times, raw request outcomes, resource intervals and configuration versions. Keep logs private and remove secrets before sharing. Use representative authenticated and write workflows only in an appropriate disposable test environment.
This test added no public diagnostic endpoint, altered no application data and left server settings unchanged. Longer runs and realistic workload mixes remain necessary for production planning.

Reference: Ubuntu vmstat manual.]]> Response times tell you that a site slowed down; simultaneous server measurements help explain why. This guide pairs a bounded WordPress traffic test with CPU, memory, swap and I/O observations on an aaPanel lab VPS.

Test environment: aaPanel Free 8.0.7, Ubuntu 22.04.5, two virtual CPUs and about 3.8GiB RAM, with Nginx, WordPress and PHP 8.5. The server also runs database, mail and other lab services. A separate Windows client generated traffic. We changed no server settings for this run.

1. Define the question before generating traffic
Are slow responses accompanied by CPU activity, memory pressure, storage waiting or application queueing? Choose a harmless lab endpoint and collect a baseline. Do not test destructive application actions or run an unlimited traffic loop.
Our test used the WordPress homepage with unique query strings. The existing FastCGI rules bypass query-string requests, verified in the earlier cache guide. A cached anonymous homepage could hide the PHP work we wanted to observe.
Start with the controlled load-test guide for request limits, TLS checks and timing definitions. This follow-up adds simultaneous resource evidence rather than repeating a capacity claim.

2. Capture memory and load snapshots
On the lab server, use a private SSH session:

Code:Copy

date -Is uptime free -h cat /proc/meminfo

Record the clock and timezone. The client and server must have reasonably aligned clocks to correlate events. Low free memory alone does not demonstrate a problem; include available memory and swap activity. A load average is also not a direct CPU percentage.
Our MemAvailable snapshots were 2,849,192KiB before and 2,813,252KiB after, approximately 2.72GiB and 2.68GiB. These are two snapshots, not the minimum available memory throughout the run.

3. Start a finite interval sampler
Our existing vmstat utility required no additional package installation. We ran:

Code:Copy

LC_ALL=C vmstat -n -t 1 25

This requests one-second updates and a finite count. Keep the output in a private administration session or log, and note the sampler's start/end time. It should overlap the request phases, not run only after the workload finishes.
The first data row includes activity averages since boot. We excluded it from interval summaries. Process and memory columns are snapshots; later activity columns cover the sampling interval. In this run we retained 24 interval rows across the traffic and surrounding idle time.

4. Understand the useful columns

• r: runnable work; compare repeated values with the CPU count, not one isolated spike.
  
• b: work blocked waiting for I/O completion.
  
• us and sy: user and kernel CPU percentages. Our CPU activity summary used 100 minus idle, I/O wait and steal.
  
• id, wa and st: idle, I/O-wait and virtual-machine steal percentages; these describe different conditions.
  
• si and so: swap-in and swap-out activity. Existing swap usage without current transfers is different from sustained swapping.
  
• bi and bo: block input/output activity. These alone do not identify which disk or application is responsible.
  

Check the local manual for units and version details. Small one-second samples can hide shorter spikes, while whole-server measurements combine activity from every service.

5. Run a bounded client workload
We used 80 requests at concurrency 4, followed by 80 at concurrency 8. Every request used HTTPS with normal certificate validation, a 15-second maximum time and no retry. The run would stop before a later phase if any request failed or its sample p95 TTFB exceeded five seconds.
The generator ran off the VPS, so its local client work did not consume the VPS CPUs being measured. It used a finite worker pool: after one request completed, a worker could submit another. This closed-loop workload does not reproduce every real traffic pattern.
Keep important service health under observation and stop if your lab becomes unstable. Do not increase concurrency just to force a failure.

6. Compare the recorded results

  monitor-load-20261014.jpg (Size: 128.09 KB / Downloads: 9)
AdminsForum formatted transcript of the original measurements, not a terminal screenshot.

• Concurrency 4: 80/80 HTTP 200, median TTFB 313ms, sample p95 467ms, elapsed phase about 10.20 seconds.
  
• Concurrency 8: 80/80 HTTP 200, median TTFB 414ms, sample p95 539ms, elapsed phase about 5.76 seconds.
  
• Across the 24 resource intervals: CPU activity peaked at 88%, I/O wait at 0%, steal at 1%, and runnable work at 6.
  
• Every interval reported zero swap-in and zero swap-out; available-memory snapshots remained about 2.7GiB.
  

The higher-concurrency phase completed its finite batch sooner but had higher median latency. These short phases were not repeated in randomized order, and other lab services may contribute to whole-server CPU activity.
The resource summary includes idle time around the test. Its peak values should not be confused with a phase average. We did not measure FPM queue lengths, individual query timing, per-process CPU attribution or device latency in this run.

7. Form a hypothesis without overstating it
The observations do not show sampled swap pressure or I/O-wait activity. CPU work is a plausible next investigation because activity increased during this request workload. They do not prove that CPU is the only bottleneck or that the VPS can sustain this traffic indefinitely.
For a stronger diagnosis, correlate process CPU, private FPM queue/status observations and application timings with the same request timestamps. Read the PHP slow-log guide to locate executing requests and the database index guide when SQL is implicated.
If storage is suspected, collect device-level latency and queue information as a separate test. A sampled wa value of zero is not proof that every storage operation was instantaneous.

8. Choose the next change from evidence
CPU-heavy PHP work may benefit from application improvements or appropriate caching; adding workers can increase contention. Memory pressure calls for examining actual process use and service budgets. Slow SQL calls for a query plan, not an arbitrary increase to max_connections.
Change one variable, retain a rollback copy and repeat the same workload with the sampler running. Check content correctness and errors as well as speed. HTTP 200 alone cannot establish that an application returned the intended page.

9. Keep the test reproducible
Save phase times, raw request outcomes, resource intervals and configuration versions. Keep logs private and remove secrets before sharing. Use representative authenticated and write workflows only in an appropriate disposable test environment.
This test added no public diagnostic endpoint, altered no application data and left server settings unchanged. Longer runs and realistic workload mixes remain necessary for production planning.

Reference: Ubuntu vmstat manual.]]> https://adminsforum.com/Thread-guide-check-website-logs-in-aapanel-to-troubleshoot-site-errors Wed, 14 Oct 2026 20:48:47 +0800 DEV]]> https://adminsforum.com/Thread-guide-check-website-logs-in-aapanel-to-troubleshoot-site-errors Start website troubleshooting by recording the failing request, its time and its HTTP status. Then match that request with the website's access log, error log and application evidence. This guide shows a real missing-file diagnosis in aaPanel and explains where to look for other failures.

Tested: aaPanel Free 8.0.7, Ubuntu 22.04.5 and Nginx 1.30.5. We inspected the native website log viewer, generated one missing-file request, matched its access/error entries and verified a temporary file corrected that request. The test file was removed afterwards. Other error types below are interpretation examples, not deliberately triggered failures.

1. Write down the symptom before changing anything
Record the exact hostname and path, time with timezone, HTTP status, request method, whether all pages fail or one route fails, and the last relevant change. Distinguish a browser connection failure from an HTTP response delivered by a server.
A request may pass through Cloudflare/CDN, Nginx, PHP-FPM and the application. A status code alone does not identify which layer caused it. Avoid restarting every service before collecting the relevant evidence.
For a harmless GET endpoint you control:

Code:Copy

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

Replace the hostname and path. Keep certificate verification enabled. This Linux example shows headers and discards the body; on Windows use curl.exe and NUL. Separately inspect the response content, because HTTP 200 can still contain an application error.

2. Open the website's native aaPanel logs
In our current interface:

• Open Website and select PHP Project.
  
• Find the exact site row and click Log.
  
• The Site modification window provides Access log and Error log views, alongside Response log and Log Security Analysis.
  
• Use Refresh to retrieve current information. The access view offers recent 50, 100, 500 or All lines and displays the source log path.
  

Labels differ between versions and project types. The main left-menu Logs section is a separate panel-wide entry; do not assume its administrative log is the website's application log. Node/Python projects have their own runtime logging to inspect as well.
Our website access log was /www/wwwlogs/adminslab.com.log; its error log was /www/wwwlogs/adminslab.com.error.log. These are lab paths, not universal names. Confirm the selected website and effective Nginx access_log/error_log directives if the viewer shows no matching entries.

3. Locate the request in the access log
The access log tells you that the server handled a request and records configured fields such as method, path, status and byte count. Our matching entry contained:

Code:Copy

[14/Oct/2026:12:40:54 +0000] GET /af-log-troubleshooting-missing-20261014.txt HTTP/2.0 404

The full entry used loopback client 127.0.0.1 because our request came from the server itself. For proxied visitor traffic, an address in a log may identify the proxy unless trusted real-IP handling is configured. Do not treat arbitrary forwarded headers as verified visitor identity.
Match the time, hostname, path and method rather than assuming the latest error belongs to your browser. Check browser/CDN caching and timezone differences when the times seem inconsistent.

4. Match the error log at the same time
At 12:40:54 UTC, our error log reported an open() failure for the expected file under /www/wwwroot/adminslab.com, with error 2: No such file or directory.
This supported a missing-file diagnosis for this static test URL. We created only that temporary file at the expected root path and repeated the request. At 12:41:34 UTC the response was HTTP 200 with the intended test content, and the access log recorded 200.


  log-troubleshooting-20261014.jpg (Size: 129.35 KB / Downloads: 8)
AdminsForum formatted transcript of our synthetic request and matching log entries, not a screenshot. Unrelated visitor entries are excluded.

We removed the fixture after verification. This was a lab demonstration, not a recommendation to create an empty file whenever a route returns 404. An application route may instead require the right document root or rewrite rules. For WordPress pretty URLs, see the permalink 404 guide.

5. Read common messages as clues

• No such file or directory: inspect the exact path, document root, deployment contents or upstream socket named by the message. A missing static file and a missing FPM socket have different fixes.
  
• Permission denied: identify the object, runtime user and required access. Review ownership, parent-directory traversal and applicable security controls; do not recursively apply chmod 777.
  
• Connection refused while connecting to upstream: inspect the configured upstream and whether the intended service is listening. Check its own error/startup logs before restarting it.
  
• Upstream timed out: investigate the upstream's workload and dependencies. Raising a timeout without finding the delay can keep resources occupied longer.
  
• PHP fatal/uncaught exception: locate the application stack and matching runtime log, then review the relevant code, dependency and recent change. A 500 is not always a PHP syntax error.
  

These are example interpretations. Use the complete message and request context. For 502 troubleshooting, correlate web-server and upstream evidence; do not use HTTP curl against a FastCGI socket as though it were an HTTP endpoint.

6. Know the difference between PHP-FPM and application logs
The lab FPM master error_log was /www/server/php/85/var/log/php-fpm.log. This captures FPM service diagnostics; it is not a guarantee that every PHP application's warning appears there.
A private FPM settings probe confirmed PHP loaded /www/server/php/85/etc/php.ini, with log_errors enabled, display_errors off and no explicit PHP error_log path. An empty PHP error_log value delegates the destination to the SAPI. Inspect the effective runtime, web-server FastCGI error output and application logger rather than assuming a file name.
The CLI runtime can load a different ini file. Never publish phpinfo or stack traces on an unprotected website just to discover a setting. Our probe was outside the web root, used through the private socket and removed afterwards.
PHP slow logs answer a different question: where a long-running worker was executing. Follow the tested slow-log guide for that workflow.

7. Check the application logger
Frameworks and CMS plugins may capture exceptions in their own log location or service journal. Check the application's documented logging configuration and make sure the runtime can write to its intended private directory.
For WordPress, official debug logging supports a chosen file path while display can remain disabled. Use a staging copy and backup before temporary debug changes; do not expose wp-content/debug.log publicly or leave development debugging enabled on a live site. This article did not alter WordPress debug settings.
For a database-related exception, examine the corresponding database evidence and query. A web-server access log usually cannot tell you which SQL statement was slow or failed.

8. Search bounded log output through SSH
If the panel cannot reach an older entry, use the actual private log paths:

Code:Copy

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

Replace example.com and the path with your own. tail -n shows recent lines; grep -F matches literal text; tail -F follows a log and can handle its replacement during rotation. Stop live following with Ctrl+C. For very large files, restrict the time/file range instead of dumping everything.
A rotated log may contain yesterday's evidence. Read the appropriate archive with supported tools; do not clear or delete logs merely to make the view shorter. Preserve useful evidence and maintain deliberate retention.

9. When no matching entry appears
Confirm that the request reached the expected server and virtual host. Check DNS, CDN responses, HTTPS/redirect paths, selected website, enabled logging and rotation. Some locations intentionally suppress logging; absence of an entry does not prove the request never happened.
If the web server cannot start, a per-site access log may be irrelevant. Inspect the server's startup/configuration error and validate the actual panel-managed configuration. For our Nginx installation the syntax check is:

Code:Copy

/www/server/nginx/sbin/nginx -t

Do not reload an invalid configuration. Retain a backup before a repair and check normal pages after applying it.

10. Verify the fix and ask for help with safe evidence
Change one identified cause, repeat the same request, inspect the new status and content, and confirm the matching fresh log entry. Check a normal page too. An old error remaining in the log does not mean the fix failed: compare timestamps.
When posting support details, include versions, affected path, time/timezone, status, last change and a small redacted matching excerpt. Remove credentials, cookies, tokens, private email addresses, visitor IPs and unrelated user data. Logs are evidence to interpret, not instructions to execute.

References: Nginx beginner's guide, PHP error logging configuration and WordPress debugging documentation.]]> Start website troubleshooting by recording the failing request, its time and its HTTP status. Then match that request with the website's access log, error log and application evidence. This guide shows a real missing-file diagnosis in aaPanel and explains where to look for other failures.

Tested: aaPanel Free 8.0.7, Ubuntu 22.04.5 and Nginx 1.30.5. We inspected the native website log viewer, generated one missing-file request, matched its access/error entries and verified a temporary file corrected that request. The test file was removed afterwards. Other error types below are interpretation examples, not deliberately triggered failures.

1. Write down the symptom before changing anything
Record the exact hostname and path, time with timezone, HTTP status, request method, whether all pages fail or one route fails, and the last relevant change. Distinguish a browser connection failure from an HTTP response delivered by a server.
A request may pass through Cloudflare/CDN, Nginx, PHP-FPM and the application. A status code alone does not identify which layer caused it. Avoid restarting every service before collecting the relevant evidence.
For a harmless GET endpoint you control:

Code:Copy

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

Replace the hostname and path. Keep certificate verification enabled. This Linux example shows headers and discards the body; on Windows use curl.exe and NUL. Separately inspect the response content, because HTTP 200 can still contain an application error.

2. Open the website's native aaPanel logs
In our current interface:

• Open Website and select PHP Project.
  
• Find the exact site row and click Log.
  
• The Site modification window provides Access log and Error log views, alongside Response log and Log Security Analysis.
  
• Use Refresh to retrieve current information. The access view offers recent 50, 100, 500 or All lines and displays the source log path.
  

Labels differ between versions and project types. The main left-menu Logs section is a separate panel-wide entry; do not assume its administrative log is the website's application log. Node/Python projects have their own runtime logging to inspect as well.
Our website access log was /www/wwwlogs/adminslab.com.log; its error log was /www/wwwlogs/adminslab.com.error.log. These are lab paths, not universal names. Confirm the selected website and effective Nginx access_log/error_log directives if the viewer shows no matching entries.

3. Locate the request in the access log
The access log tells you that the server handled a request and records configured fields such as method, path, status and byte count. Our matching entry contained:

Code:Copy

[14/Oct/2026:12:40:54 +0000] GET /af-log-troubleshooting-missing-20261014.txt HTTP/2.0 404

The full entry used loopback client 127.0.0.1 because our request came from the server itself. For proxied visitor traffic, an address in a log may identify the proxy unless trusted real-IP handling is configured. Do not treat arbitrary forwarded headers as verified visitor identity.
Match the time, hostname, path and method rather than assuming the latest error belongs to your browser. Check browser/CDN caching and timezone differences when the times seem inconsistent.

4. Match the error log at the same time
At 12:40:54 UTC, our error log reported an open() failure for the expected file under /www/wwwroot/adminslab.com, with error 2: No such file or directory.
This supported a missing-file diagnosis for this static test URL. We created only that temporary file at the expected root path and repeated the request. At 12:41:34 UTC the response was HTTP 200 with the intended test content, and the access log recorded 200.


  log-troubleshooting-20261014.jpg (Size: 129.35 KB / Downloads: 8)
AdminsForum formatted transcript of our synthetic request and matching log entries, not a screenshot. Unrelated visitor entries are excluded.

We removed the fixture after verification. This was a lab demonstration, not a recommendation to create an empty file whenever a route returns 404. An application route may instead require the right document root or rewrite rules. For WordPress pretty URLs, see the permalink 404 guide.

5. Read common messages as clues

• No such file or directory: inspect the exact path, document root, deployment contents or upstream socket named by the message. A missing static file and a missing FPM socket have different fixes.
  
• Permission denied: identify the object, runtime user and required access. Review ownership, parent-directory traversal and applicable security controls; do not recursively apply chmod 777.
  
• Connection refused while connecting to upstream: inspect the configured upstream and whether the intended service is listening. Check its own error/startup logs before restarting it.
  
• Upstream timed out: investigate the upstream's workload and dependencies. Raising a timeout without finding the delay can keep resources occupied longer.
  
• PHP fatal/uncaught exception: locate the application stack and matching runtime log, then review the relevant code, dependency and recent change. A 500 is not always a PHP syntax error.
  

These are example interpretations. Use the complete message and request context. For 502 troubleshooting, correlate web-server and upstream evidence; do not use HTTP curl against a FastCGI socket as though it were an HTTP endpoint.

6. Know the difference between PHP-FPM and application logs
The lab FPM master error_log was /www/server/php/85/var/log/php-fpm.log. This captures FPM service diagnostics; it is not a guarantee that every PHP application's warning appears there.
A private FPM settings probe confirmed PHP loaded /www/server/php/85/etc/php.ini, with log_errors enabled, display_errors off and no explicit PHP error_log path. An empty PHP error_log value delegates the destination to the SAPI. Inspect the effective runtime, web-server FastCGI error output and application logger rather than assuming a file name.
The CLI runtime can load a different ini file. Never publish phpinfo or stack traces on an unprotected website just to discover a setting. Our probe was outside the web root, used through the private socket and removed afterwards.
PHP slow logs answer a different question: where a long-running worker was executing. Follow the tested slow-log guide for that workflow.

7. Check the application logger
Frameworks and CMS plugins may capture exceptions in their own log location or service journal. Check the application's documented logging configuration and make sure the runtime can write to its intended private directory.
For WordPress, official debug logging supports a chosen file path while display can remain disabled. Use a staging copy and backup before temporary debug changes; do not expose wp-content/debug.log publicly or leave development debugging enabled on a live site. This article did not alter WordPress debug settings.
For a database-related exception, examine the corresponding database evidence and query. A web-server access log usually cannot tell you which SQL statement was slow or failed.

8. Search bounded log output through SSH
If the panel cannot reach an older entry, use the actual private log paths:

Code:Copy

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

Replace example.com and the path with your own. tail -n shows recent lines; grep -F matches literal text; tail -F follows a log and can handle its replacement during rotation. Stop live following with Ctrl+C. For very large files, restrict the time/file range instead of dumping everything.
A rotated log may contain yesterday's evidence. Read the appropriate archive with supported tools; do not clear or delete logs merely to make the view shorter. Preserve useful evidence and maintain deliberate retention.

9. When no matching entry appears
Confirm that the request reached the expected server and virtual host. Check DNS, CDN responses, HTTPS/redirect paths, selected website, enabled logging and rotation. Some locations intentionally suppress logging; absence of an entry does not prove the request never happened.
If the web server cannot start, a per-site access log may be irrelevant. Inspect the server's startup/configuration error and validate the actual panel-managed configuration. For our Nginx installation the syntax check is:

Code:Copy

/www/server/nginx/sbin/nginx -t

Do not reload an invalid configuration. Retain a backup before a repair and check normal pages after applying it.

10. Verify the fix and ask for help with safe evidence
Change one identified cause, repeat the same request, inspect the new status and content, and confirm the matching fresh log entry. Check a normal page too. An old error remaining in the log does not mean the fix failed: compare timestamps.
When posting support details, include versions, affected path, time/timezone, status, last change and a small redacted matching excerpt. Remove credentials, cookies, tokens, private email addresses, visitor IPs and unrelated user data. Logs are evidence to interpret, not instructions to execute.

References: Nginx beginner's guide, PHP error logging configuration and WordPress debugging documentation.]]> https://adminsforum.com/Thread-guide-verify-wordpress-fastcgi-cache-hits-and-bypass-rules-in-aapanel Wed, 14 Oct 2026 20:24:21 +0800 DEV]]> https://adminsforum.com/Thread-guide-verify-wordpress-fastcgi-cache-hits-and-bypass-rules-in-aapanel FastCGI page caching can let Nginx answer an anonymous request without running PHP. Verify both cache hits and exclusions before relying on it: private or personalized responses must not be served from a shared anonymous cache.

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

1. Identify the cache layer
Page caching stores a rendered HTTP response. OPcache stores compiled PHP bytecode; Redis object caching stores application objects. They solve different problems. A page-cache HIT may avoid PHP, so it cannot be used to measure PHP or SQL tuning alone.
Inspect the website's Nginx configuration and included PHP handler. Our WordPress site included enable-php-85-wpfastcgi.conf and used a WORDPRESS FastCGI cache zone.

2. Read the rules before testing
Our existing rules bypassed POST requests, nonempty query strings, WordPress administrative/login-related paths and cookies matching WordPress login or password-protected content. These rules must be checked against the actual applications on the site.
The handler used both:

Code:Copy

fastcgi_cache_bypass $skip_cache; fastcgi_no_cache $skip_cache;

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

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

Code:Copy

curl -sS -D - -o /dev/null https://example.com/

Replace the hostname. Read the HTTP status and cache header. HIT means a stored response was served. MISS means the cache did not supply an entry; an eligible response may subsequently be stored. BYPASS means the rules skipped reading the cache. Absence of a header does not prove caching is disabled.

4. Repeat an anonymous request
We sent five sequential requests to the same lab homepage over loopback HTTPS with certificate validation. All five returned HTTP 200 and HIT; median time to first byte was approximately 58ms.
The page was already cached. We did not claim to demonstrate a fresh MISS-to-HIT transition, clear the whole cache or measure maximum throughput. Five requests are a small diagnostic sample.

5. Check query and cookie exclusions

Code:Copy

curl -sS -D - -o /dev/null 'https://example.com/?cache_check=1' curl -sS -D - -o /dev/null \   -H 'Cookie: wordpress_logged_in_lab=synthetic-test' https://example.com/ curl -sS -D - -o /dev/null https://example.com/wp-login.php

The query-string request, synthetic login-cookie request and login page each returned HTTP 200 and BYPASS in our lab. The synthetic cookie contains no real login token; it tests the configured cookie-name rule only. It does not authenticate a user or prove actual account privacy end to end.


  cache-performance-20261014.jpg (Size: 105.63 KB / Downloads: 7)
AdminsForum formatted transcript of the original checks, not a screenshot.

6. Test actual personalized workflows before rollout
With a controlled test account, verify that logged-in pages, shopping carts, checkout, account settings and password-protected content are excluded. Test two separate sessions and inspect rendered content, not just a fast response. Review authorization, cookies, cache keys and application-specific paths.
Our short check did not perform these authenticated workflows. Treat them as required verification before enabling shared page caching for a real personalized application.

7. Verify freshness and controlled purging
After updating a public test page, confirm when anonymous visitors receive the new content. Purge the relevant cache entry using your supported administration workflow and verify the result. Do not expose an unrestricted public purge endpoint.
Our existing configuration restricted its purge location to loopback. We did not weaken that restriction or perform a global purge for this guide. Cache lifetime and invalidation should match how frequently your pages change.

8. Troubleshoot a persistent BYPASS or stale page
Check whether a query string, cookie, request method or path matches an exclusion. Inspect the effective Nginx configuration and logs. If a public page bypasses unexpectedly, identify the cause rather than deleting all exclusions.
For stale content, check the correct hostname, cache key, purge method and any additional CDN or browser cache. A browser refresh alone may leave server caches untouched.
Back up before changing rules, validate Nginx syntax, reload and repeat both anonymous and private-response tests. Restore the original rules if personalized content is cached or application behavior changes.

Reference: Official Nginx FastCGI cache controls.]]> FastCGI page caching can let Nginx answer an anonymous request without running PHP. Verify both cache hits and exclusions before relying on it: private or personalized responses must not be served from a shared anonymous cache.

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

1. Identify the cache layer
Page caching stores a rendered HTTP response. OPcache stores compiled PHP bytecode; Redis object caching stores application objects. They solve different problems. A page-cache HIT may avoid PHP, so it cannot be used to measure PHP or SQL tuning alone.
Inspect the website's Nginx configuration and included PHP handler. Our WordPress site included enable-php-85-wpfastcgi.conf and used a WORDPRESS FastCGI cache zone.

2. Read the rules before testing
Our existing rules bypassed POST requests, nonempty query strings, WordPress administrative/login-related paths and cookies matching WordPress login or password-protected content. These rules must be checked against the actual applications on the site.
The handler used both:

Code:Copy

fastcgi_cache_bypass $skip_cache; fastcgi_no_cache $skip_cache;

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

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

Code:Copy

curl -sS -D - -o /dev/null https://example.com/

Replace the hostname. Read the HTTP status and cache header. HIT means a stored response was served. MISS means the cache did not supply an entry; an eligible response may subsequently be stored. BYPASS means the rules skipped reading the cache. Absence of a header does not prove caching is disabled.

4. Repeat an anonymous request
We sent five sequential requests to the same lab homepage over loopback HTTPS with certificate validation. All five returned HTTP 200 and HIT; median time to first byte was approximately 58ms.
The page was already cached. We did not claim to demonstrate a fresh MISS-to-HIT transition, clear the whole cache or measure maximum throughput. Five requests are a small diagnostic sample.

5. Check query and cookie exclusions

Code:Copy

curl -sS -D - -o /dev/null 'https://example.com/?cache_check=1' curl -sS -D - -o /dev/null \   -H 'Cookie: wordpress_logged_in_lab=synthetic-test' https://example.com/ curl -sS -D - -o /dev/null https://example.com/wp-login.php

The query-string request, synthetic login-cookie request and login page each returned HTTP 200 and BYPASS in our lab. The synthetic cookie contains no real login token; it tests the configured cookie-name rule only. It does not authenticate a user or prove actual account privacy end to end.


  cache-performance-20261014.jpg (Size: 105.63 KB / Downloads: 7)
AdminsForum formatted transcript of the original checks, not a screenshot.

6. Test actual personalized workflows before rollout
With a controlled test account, verify that logged-in pages, shopping carts, checkout, account settings and password-protected content are excluded. Test two separate sessions and inspect rendered content, not just a fast response. Review authorization, cookies, cache keys and application-specific paths.
Our short check did not perform these authenticated workflows. Treat them as required verification before enabling shared page caching for a real personalized application.

7. Verify freshness and controlled purging
After updating a public test page, confirm when anonymous visitors receive the new content. Purge the relevant cache entry using your supported administration workflow and verify the result. Do not expose an unrestricted public purge endpoint.
Our existing configuration restricted its purge location to loopback. We did not weaken that restriction or perform a global purge for this guide. Cache lifetime and invalidation should match how frequently your pages change.

8. Troubleshoot a persistent BYPASS or stale page
Check whether a query string, cookie, request method or path matches an exclusion. Inspect the effective Nginx configuration and logs. If a public page bypasses unexpectedly, identify the cause rather than deleting all exclusions.
For stale content, check the correct hostname, cache key, purge method and any additional CDN or browser cache. A browser refresh alone may leave server caches untouched.
Back up before changing rules, validate Nginx syntax, reload and repeat both anonymous and private-response tests. Restore the original rules if personalized content is cached or application behavior changes.

Reference: Official Nginx FastCGI cache controls.]]> https://adminsforum.com/Thread-guide-run-a-controlled-wordpress-load-test-on-an-aapanel-vps Wed, 14 Oct 2026 20:22:42 +0800 DEV]]> https://adminsforum.com/Thread-guide-run-a-controlled-wordpress-load-test-on-an-aapanel-vps A controlled load test helps compare one workload at several concurrency levels. It does not prove how many visitors an entire website can support. This guide records a bounded external-client test and explains the measurements still needed for a production decision.

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

1. Choose a safe target and scope
Use a lab server you control. Choose a harmless GET endpoint and a finite request count. Exclude actions that create accounts, orders, mail or database writes. Agree a maintenance window for production testing and monitor other services sharing the machine.
Our target was the WordPress homepage with a unique test query on each request. We verified the query rule returned Nginx-Cache: BYPASS before the run. This measures an uncached homepage path, not checkout, search, login or an entire browsing session.

2. Record the baseline and configuration
Write down PHP version, FPM worker limits, cache states, database version and application version/plugins. Keep those constant between phases. Record server memory, swap and CPU before testing; arrange an interval resource sampler if you need to locate saturation.
This run did not collect a simultaneous server resource trace. We therefore report response results without claiming whether PHP, CPU or SQL limited throughput.

3. Set explicit limits and stop conditions
Our client used 40 requests per phase at concurrency 2, then 4, then 8. Each curl request had a 15-second maximum time, used normal HTTPS certificate validation and performed no retries. Later phases would stop if any request failed or the sample p95 time to first byte exceeded five seconds.
A short request count bounds the total work but can miss sustained bottlenecks. Avoid unbounded loops and high concurrency simply to generate a dramatic result. Watch availability and stop manually if important services degrade.

4. Understand the client measurements
A single request example is:

Code:Copy

curl.exe -sS --max-time 15 -o NUL \   -w "%{http_code} %{time_starttransfer} %{time_total}" \   "https://example.com/?load_test=unique_value"

This is a Windows example: NUL discards the body. Use /dev/null on Linux. Replace the hostname and make each test query unique if your verified rules use query strings to bypass caching. Do not disable certificate checks.
Time to first byte includes client-side connection and network effects as well as server waiting. Total time includes body transfer. An HTTP 200 alone does not prove the content is correct; separately inspect a sample response for application errors.
We used a bounded client worker pool to run the finite requests concurrently, waited for each phase to complete, then calculated its results. These are closed-loop tests: workers submit another request after the previous one finishes, rather than maintaining a fixed independent arrival rate.

5. Read the actual results

  load-performance-20261014.jpg (Size: 124.63 KB / Downloads: 6)
AdminsForum formatted transcript of the original client test, not a screenshot.

• Concurrency 2: 40/40 HTTP 200; median TTFB 295ms; sample p95 334ms; phase elapsed 8.46 seconds; about 4.73 completed requests/second.
  
• Concurrency 4: 40/40 HTTP 200; median TTFB 334ms; sample p95 431ms; phase elapsed 4.91 seconds; about 8.15 completed requests/second.
  
• Concurrency 8: 40/40 HTTP 200; median TTFB 377ms; sample p95 609ms; phase elapsed 2.88 seconds; about 13.87 completed requests/second.
  

All 120 requests completed with HTTP 200 and no client request failure. Concurrency increased the observed completion rate and latency. The phases were short, were not repeated in randomized order, and did not isolate cache-warmth or resource effects. Do not interpret the numbers as a guaranteed sustained rate or maximum visitors.
The sample p95 is a nearest-rank estimate from forty observations, not a precise long-term tail metric. Network variation and shared-server activity can affect it.

6. Add resource evidence before tuning
For a repeat test, sample CPU utilization, iowait, free memory, swap activity, FPM queues and active database work throughout the phases. Private FPM status and slow logs can help locate queueing. Keep diagnostic endpoints private and redact logs before sharing.
If latency rises with CPU saturation, more FPM workers may worsen contention. If queries dominate, inspect SQL plans. If the client itself is saturated, the generator may be the limit. These conclusions need measurements; this run does not establish them.

7. Repeat a representative workload
Use the same test after one targeted change. Include realistic page mixes, authenticated workflows under controlled accounts, writes in a disposable environment and sustained runs appropriate to your service. Measure errors and content correctness alongside latency.
Test anonymous cache HIT and uncached behavior separately. A fast cached homepage cannot prove that private or dynamic pages perform well. Never increase a pool limit solely because a cached benchmark looks good.

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

Use the baseline guide, the measured PHP-FPM pool guide and the database index test as a repeatable series. Present the workload and its limits whenever quoting performance numbers.]]> A controlled load test helps compare one workload at several concurrency levels. It does not prove how many visitors an entire website can support. This guide records a bounded external-client test and explains the measurements still needed for a production decision.

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

1. Choose a safe target and scope
Use a lab server you control. Choose a harmless GET endpoint and a finite request count. Exclude actions that create accounts, orders, mail or database writes. Agree a maintenance window for production testing and monitor other services sharing the machine.
Our target was the WordPress homepage with a unique test query on each request. We verified the query rule returned Nginx-Cache: BYPASS before the run. This measures an uncached homepage path, not checkout, search, login or an entire browsing session.

2. Record the baseline and configuration
Write down PHP version, FPM worker limits, cache states, database version and application version/plugins. Keep those constant between phases. Record server memory, swap and CPU before testing; arrange an interval resource sampler if you need to locate saturation.
This run did not collect a simultaneous server resource trace. We therefore report response results without claiming whether PHP, CPU or SQL limited throughput.

3. Set explicit limits and stop conditions
Our client used 40 requests per phase at concurrency 2, then 4, then 8. Each curl request had a 15-second maximum time, used normal HTTPS certificate validation and performed no retries. Later phases would stop if any request failed or the sample p95 time to first byte exceeded five seconds.
A short request count bounds the total work but can miss sustained bottlenecks. Avoid unbounded loops and high concurrency simply to generate a dramatic result. Watch availability and stop manually if important services degrade.

4. Understand the client measurements
A single request example is:

Code:Copy

curl.exe -sS --max-time 15 -o NUL \   -w "%{http_code} %{time_starttransfer} %{time_total}" \   "https://example.com/?load_test=unique_value"

This is a Windows example: NUL discards the body. Use /dev/null on Linux. Replace the hostname and make each test query unique if your verified rules use query strings to bypass caching. Do not disable certificate checks.
Time to first byte includes client-side connection and network effects as well as server waiting. Total time includes body transfer. An HTTP 200 alone does not prove the content is correct; separately inspect a sample response for application errors.
We used a bounded client worker pool to run the finite requests concurrently, waited for each phase to complete, then calculated its results. These are closed-loop tests: workers submit another request after the previous one finishes, rather than maintaining a fixed independent arrival rate.

5. Read the actual results

  load-performance-20261014.jpg (Size: 124.63 KB / Downloads: 6)
AdminsForum formatted transcript of the original client test, not a screenshot.

• Concurrency 2: 40/40 HTTP 200; median TTFB 295ms; sample p95 334ms; phase elapsed 8.46 seconds; about 4.73 completed requests/second.
  
• Concurrency 4: 40/40 HTTP 200; median TTFB 334ms; sample p95 431ms; phase elapsed 4.91 seconds; about 8.15 completed requests/second.
  
• Concurrency 8: 40/40 HTTP 200; median TTFB 377ms; sample p95 609ms; phase elapsed 2.88 seconds; about 13.87 completed requests/second.
  

All 120 requests completed with HTTP 200 and no client request failure. Concurrency increased the observed completion rate and latency. The phases were short, were not repeated in randomized order, and did not isolate cache-warmth or resource effects. Do not interpret the numbers as a guaranteed sustained rate or maximum visitors.
The sample p95 is a nearest-rank estimate from forty observations, not a precise long-term tail metric. Network variation and shared-server activity can affect it.

6. Add resource evidence before tuning
For a repeat test, sample CPU utilization, iowait, free memory, swap activity, FPM queues and active database work throughout the phases. Private FPM status and slow logs can help locate queueing. Keep diagnostic endpoints private and redact logs before sharing.
If latency rises with CPU saturation, more FPM workers may worsen contention. If queries dominate, inspect SQL plans. If the client itself is saturated, the generator may be the limit. These conclusions need measurements; this run does not establish them.

7. Repeat a representative workload
Use the same test after one targeted change. Include realistic page mixes, authenticated workflows under controlled accounts, writes in a disposable environment and sustained runs appropriate to your service. Measure errors and content correctness alongside latency.
Test anonymous cache HIT and uncached behavior separately. A fast cached homepage cannot prove that private or dynamic pages perform well. Never increase a pool limit solely because a cached benchmark looks good.

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

Use the baseline guide, the measured PHP-FPM pool guide and the database index test as a repeatable series. Present the workload and its limits whenever quoting performance numbers.]]> https://adminsforum.com/Thread-guide-test-nginx-performance-and-gzip-compression-in-aapanel Wed, 14 Oct 2026 20:21:21 +0800 DEV]]> https://adminsforum.com/Thread-guide-test-nginx-performance-and-gzip-compression-in-aapanel Nginx tuning should start with measurements, not a list of larger limits. This guide checks worker settings and gzip behavior, demonstrates a real compression tradeoff, and explains when to restore a change.

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

1. Inspect the active configuration
Open App Store → Installed → Nginx → Setting and inspect its configuration. Paths and interface labels can differ by release. Our global file was /www/server/nginx/conf/nginx.conf; website configurations were included separately.
A configuration dump can help identify includes:

Code:Copy

/www/server/nginx/sbin/nginx -T

Keep the output private because it can reveal hostnames, paths and configuration details. Identify which file owns the directive before editing it.

2. Review workers and connection limits
Our server already used worker_processes auto and worker_connections 51200. We did not increase either. More permitted connections do not mean more requests per second: upstream connections, open-file limits, PHP workers, database work and CPU also constrain throughput.
Inspect actual worker count, active connections, system file limits and errors during representative traffic. Raise a limit only if it is the observed bottleneck and the server has resources to support it. Avoid treating a high worker_connections value as a visitor-capacity guarantee.
Keepalive settings also need workload evidence. Shorter idle time can reduce held connections but increase connection setup; longer idle time can retain resources. We left the existing 60-second setting unchanged.

3. Back up before a compression experiment
Make a private copy of the active file. Our baseline already had gzip enabled, a 1KiB minimum length, compression level 5 and gzip_vary on. Its gzip_types included text, JavaScript, CSS, JSON and several image types.
Inspect response headers and actual transfer sizes before changing MIME types. Many image formats contain compressed data, but the effect of an additional gzip layer depends on the particular file.

4. Test text and image responses
We created an original 24,500-byte text fixture in the lab website and used an existing 3,113-byte WordPress PNG. We requested gzip explicitly over loopback HTTPS with normal certificate validation.
A basic header check is:

Code:Copy

curl -sS -D - -o /dev/null \   -H 'Accept-Encoding: gzip' https://example.com/test.txt

Use your own hostname and a safe test file. Inspect Content-Encoding, Vary and HTTP status. To compare raw encoded bytes, save the response body without automatic decompression. curl --compressed instead requests supported compression and decompresses the body, so do not confuse decoded size with wire size.
Our test compared the baseline against removing JPEG/GIF/PNG from gzip_types. It did not change the compression level or worker limits.


  nginx-performance-20261014.jpg (Size: 116.44 KB / Downloads: 4)
AdminsForum formatted transcript of the experiment, not a screenshot.

5. Interpret the evidence

• Text: gzip was used in both phases; the body transferred was 156 bytes and decoded to 24,500 bytes.
  
• PNG before: gzip body 2,487 bytes, decoded to 3,113 bytes.
  
• PNG after: no gzip; body transferred 3,113 bytes.
  
• All responses returned HTTP 200, and decoded content hashes matched.
  

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

6. Validate, reload and restore when appropriate

Code:Copy

/www/server/nginx/sbin/nginx -t /www/server/nginx/sbin/nginx -s reload

Validation passed for the experiment. Because we had no demonstrated overall benefit, we restored the original configuration, validated it again and reloaded Nginx. A successful reload is not an application test: check important pages, TLS, redirects, upstream errors and logs afterwards.
Do not keep an optimization solely because it looks conventional. Record the tradeoff and test enough representative content to support a decision.

7. Apply this method to a real high-traffic site
Collect response latency, transfer sizes, CPU, connection counts and upstream timing over comparable windows. Separate cached and uncached requests. Change one variable at a time and repeat the same workload. Keep a rollback copy and stop if errors or resource pressure increase.
A compression change cannot repair slow SQL or exhausted PHP workers. Use the database and PHP-FPM guides alongside this test, then investigate the bottleneck actually observed.

Reference: Official Nginx gzip module documentation.]]> Nginx tuning should start with measurements, not a list of larger limits. This guide checks worker settings and gzip behavior, demonstrates a real compression tradeoff, and explains when to restore a change.

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

1. Inspect the active configuration
Open App Store → Installed → Nginx → Setting and inspect its configuration. Paths and interface labels can differ by release. Our global file was /www/server/nginx/conf/nginx.conf; website configurations were included separately.
A configuration dump can help identify includes:

Code:Copy

/www/server/nginx/sbin/nginx -T

Keep the output private because it can reveal hostnames, paths and configuration details. Identify which file owns the directive before editing it.

2. Review workers and connection limits
Our server already used worker_processes auto and worker_connections 51200. We did not increase either. More permitted connections do not mean more requests per second: upstream connections, open-file limits, PHP workers, database work and CPU also constrain throughput.
Inspect actual worker count, active connections, system file limits and errors during representative traffic. Raise a limit only if it is the observed bottleneck and the server has resources to support it. Avoid treating a high worker_connections value as a visitor-capacity guarantee.
Keepalive settings also need workload evidence. Shorter idle time can reduce held connections but increase connection setup; longer idle time can retain resources. We left the existing 60-second setting unchanged.

3. Back up before a compression experiment
Make a private copy of the active file. Our baseline already had gzip enabled, a 1KiB minimum length, compression level 5 and gzip_vary on. Its gzip_types included text, JavaScript, CSS, JSON and several image types.
Inspect response headers and actual transfer sizes before changing MIME types. Many image formats contain compressed data, but the effect of an additional gzip layer depends on the particular file.

4. Test text and image responses
We created an original 24,500-byte text fixture in the lab website and used an existing 3,113-byte WordPress PNG. We requested gzip explicitly over loopback HTTPS with normal certificate validation.
A basic header check is:

Code:Copy

curl -sS -D - -o /dev/null \   -H 'Accept-Encoding: gzip' https://example.com/test.txt

Use your own hostname and a safe test file. Inspect Content-Encoding, Vary and HTTP status. To compare raw encoded bytes, save the response body without automatic decompression. curl --compressed instead requests supported compression and decompresses the body, so do not confuse decoded size with wire size.
Our test compared the baseline against removing JPEG/GIF/PNG from gzip_types. It did not change the compression level or worker limits.


  nginx-performance-20261014.jpg (Size: 116.44 KB / Downloads: 4)
AdminsForum formatted transcript of the experiment, not a screenshot.

5. Interpret the evidence

• Text: gzip was used in both phases; the body transferred was 156 bytes and decoded to 24,500 bytes.
  
• PNG before: gzip body 2,487 bytes, decoded to 3,113 bytes.
  
• PNG after: no gzip; body transferred 3,113 bytes.
  
• All responses returned HTTP 200, and decoded content hashes matched.
  

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

6. Validate, reload and restore when appropriate

Code:Copy

/www/server/nginx/sbin/nginx -t /www/server/nginx/sbin/nginx -s reload

Validation passed for the experiment. Because we had no demonstrated overall benefit, we restored the original configuration, validated it again and reloaded Nginx. A successful reload is not an application test: check important pages, TLS, redirects, upstream errors and logs afterwards.
Do not keep an optimization solely because it looks conventional. Record the tradeoff and test enough representative content to support a decision.

7. Apply this method to a real high-traffic site
Collect response latency, transfer sizes, CPU, connection counts and upstream timing over comparable windows. Separate cached and uncached requests. Change one variable at a time and repeat the same workload. Keep a rollback copy and stop if errors or resource pressure increase.
A compression change cannot repair slow SQL or exhausted PHP workers. Use the database and PHP-FPM guides alongside this test, then investigate the bottleneck actually observed.

Reference: Official Nginx gzip module documentation.]]> https://adminsforum.com/Thread-guide-measure-aapanel-website-performance-before-tuning-your-server Wed, 14 Oct 2026 18:32:23 +0800 DEV]]> https://adminsforum.com/Thread-guide-measure-aapanel-website-performance-before-tuning-your-server Before fine-tuning PHP-FPM, SQL or Nginx for a busy website, record a repeatable baseline. Measure response time and errors alongside server resources so later changes can be compared with the same workload.

Series introduction: This lesson records low-load observations on our aaPanel Free 8.0.7 lab. It does not stress-test the server, prove maximum visitor capacity or recommend universal tuning values. PHP-FPM, OPcache, database and caching tuning belong in separate measured lessons.

1. Describe the server and workload
Our lab VPS has two available CPUs, 3.8Gi RAM and a root/data filesystem reporting 39G capacity. Installed components include Nginx 1.30.5 and MariaDB 10.11.10. The PHP 8.5 CLI binary reports 8.5.11; a CLI version alone is not proof of a website's active PHP-FPM runtime.

Record the site's selected PHP version in aaPanel, application version, database implementation, URL, authentication state, cache state and any CDN/proxy. A cached anonymous homepage and a logged-in database-heavy request are different workloads. Identify representative pages before deciding what needs tuning.

2. Check server resources before the sample
From SSH:

Code:Copy

nproc uptime free -h df -h /www

Our snapshot showed load averages of 0.32, 0.18 and 0.11, about 2.7Gi available memory, no swap used and 30% disk usage. Those are observations at the time of testing, not permanent operating conditions. See VPS resource checks for interpretation.

For serious performance work, capture CPU, memory, swap and disk-I/O behavior across the same period as the workload. A single before/after snapshot does not establish peak resource use or rule out brief pressure.

3. Measure a normal HTTPS request
On Linux or macOS, a simple diagnostic command is:

Code:Copy

curl -sS --max-time 20 -o /dev/null  -w 'HTTP=%{http_code} TTFB=%{time_starttransfer} TOTAL=%{time_total} '  https://your-test-hostname/

On Windows PowerShell use curl.exe and NUL as the output destination. Our test used:

Code:Copy

curl.exe -sS --max-time 20 -o NUL -w "HTTP=%{http_code} TTFB=%{time_starttransfer} TOTAL=%{time_total}" https://your-test-hostname/

Use a hostname you control and keep normal certificate validation enabled. Check the exit code as well as HTTP status; a timeout or TLS failure should count as a failed request rather than disappearing from the results.

How to read the measurements

• HTTP status: check whether the response is expected; a fast error is not a fast successful page.
  
• TTFB: curl's time_starttransfer is elapsed time until the first response byte, including connection-related work. It is not isolated PHP execution time.
  
• Total: time until that single response transfer completes. It does not include rendering a browser page or downloading its complete asset graph.
  

Validate the response content once as well. Timing a redirect, error template or login page instead of the intended content creates a misleading comparison.

4. Repeat a small sequential sample
We sent ten separate sequential requests to the static lab homepage and ten to the WordPress lab homepage, with a short delay between requests. Each request used a fresh curl process. This was a small diagnostic sample, not a concurrent load test.


  performance-baseline-transcript-20261014.jpg (Size: 117.57 KB / Downloads: 9)
Measured lab results, rounded for readability. The image is a formatted transcript rather than a performance guarantee.

Our client-side results were:

• Static lab: 10/10 requests returned HTTP 200. Median TTFB 149 ms; slowest total response 240 ms.
  
• WordPress lab: 10/10 requests returned HTTP 200. Median TTFB 184 ms; slowest total response 424 ms.
  

These timings include the network path from our client. We did not independently isolate application cache state, PHP time or SQL time in this introductory sample. The ten-request sample is too small to make strong tail-latency or capacity claims.

5. Record enough information to repeat the test
Keep the timestamp and timezone, client location, exact URL, request count, whether requests are sequential/concurrent, timeout, status/exit results and software/configuration versions. Note whether the response came from a CDN/cache or the origin if you have verified that distinction.

Repeat from the same client using the same workload when comparing a tuning change. Also test the actual user workflow: anonymous content, logged-in pages, search and writes can have very different costs. Do not combine those outcomes into one unexplained average.

6. Choose the next investigation from evidence

• PHP worker queues or saturation: inspect PHP-FPM status/slow logs and memory per worker before choosing pm.max_children.
  
• Database-heavy requests: inspect slow queries, query plans, indexes and connection behavior before increasing SQL limits.
  
• Repeated anonymous content: evaluate page caching with appropriate exclusions for private or changing content.
  
• High I/O wait: investigate storage and query/file access rather than assuming more PHP workers will help.
  
• Slow assets/rendering: measure browser/frontend behavior; an origin response test alone cannot explain it.
  

A worker limit should account for measured application memory use and RAM reserved for the database, operating system and other services. A database buffer setting must fit the real shared workload. Raising every limit can increase memory pressure instead of throughput.

7. Plan a controlled comparison
Back up the exact configuration before editing it. Change one meaningful setting at a time, validate configuration, repeat the same test and compare latency, error rate and resource use. Define rollback conditions before applying changes.

A later controlled load test should use an authorized lab target, bounded duration and concurrency, realistic requests and clear stop conditions. Do not infer requests-per-second capacity or supported monthly visitors from the small sequential sample in this guide.

What this guide verified
Two lab URLs each returned HTTP 200 for ten sequential client requests. We recorded client response timings and a server-resource snapshot. No PHP, database or Nginx tuning, stress test or production configuration change was performed.

AdminsForum performance series, lesson 1: baseline measurement. Later lessons will compare specific changes against documented workloads.]]> Before fine-tuning PHP-FPM, SQL or Nginx for a busy website, record a repeatable baseline. Measure response time and errors alongside server resources so later changes can be compared with the same workload.

Series introduction: This lesson records low-load observations on our aaPanel Free 8.0.7 lab. It does not stress-test the server, prove maximum visitor capacity or recommend universal tuning values. PHP-FPM, OPcache, database and caching tuning belong in separate measured lessons.

1. Describe the server and workload
Our lab VPS has two available CPUs, 3.8Gi RAM and a root/data filesystem reporting 39G capacity. Installed components include Nginx 1.30.5 and MariaDB 10.11.10. The PHP 8.5 CLI binary reports 8.5.11; a CLI version alone is not proof of a website's active PHP-FPM runtime.

Record the site's selected PHP version in aaPanel, application version, database implementation, URL, authentication state, cache state and any CDN/proxy. A cached anonymous homepage and a logged-in database-heavy request are different workloads. Identify representative pages before deciding what needs tuning.

2. Check server resources before the sample
From SSH:

Code:Copy

nproc uptime free -h df -h /www

Our snapshot showed load averages of 0.32, 0.18 and 0.11, about 2.7Gi available memory, no swap used and 30% disk usage. Those are observations at the time of testing, not permanent operating conditions. See VPS resource checks for interpretation.

For serious performance work, capture CPU, memory, swap and disk-I/O behavior across the same period as the workload. A single before/after snapshot does not establish peak resource use or rule out brief pressure.

3. Measure a normal HTTPS request
On Linux or macOS, a simple diagnostic command is:

Code:Copy

curl -sS --max-time 20 -o /dev/null  -w 'HTTP=%{http_code} TTFB=%{time_starttransfer} TOTAL=%{time_total} '  https://your-test-hostname/

On Windows PowerShell use curl.exe and NUL as the output destination. Our test used:

Code:Copy

curl.exe -sS --max-time 20 -o NUL -w "HTTP=%{http_code} TTFB=%{time_starttransfer} TOTAL=%{time_total}" https://your-test-hostname/

Use a hostname you control and keep normal certificate validation enabled. Check the exit code as well as HTTP status; a timeout or TLS failure should count as a failed request rather than disappearing from the results.

How to read the measurements

• HTTP status: check whether the response is expected; a fast error is not a fast successful page.
  
• TTFB: curl's time_starttransfer is elapsed time until the first response byte, including connection-related work. It is not isolated PHP execution time.
  
• Total: time until that single response transfer completes. It does not include rendering a browser page or downloading its complete asset graph.
  

Validate the response content once as well. Timing a redirect, error template or login page instead of the intended content creates a misleading comparison.

4. Repeat a small sequential sample
We sent ten separate sequential requests to the static lab homepage and ten to the WordPress lab homepage, with a short delay between requests. Each request used a fresh curl process. This was a small diagnostic sample, not a concurrent load test.


  performance-baseline-transcript-20261014.jpg (Size: 117.57 KB / Downloads: 9)
Measured lab results, rounded for readability. The image is a formatted transcript rather than a performance guarantee.

Our client-side results were:

• Static lab: 10/10 requests returned HTTP 200. Median TTFB 149 ms; slowest total response 240 ms.
  
• WordPress lab: 10/10 requests returned HTTP 200. Median TTFB 184 ms; slowest total response 424 ms.
  

These timings include the network path from our client. We did not independently isolate application cache state, PHP time or SQL time in this introductory sample. The ten-request sample is too small to make strong tail-latency or capacity claims.

5. Record enough information to repeat the test
Keep the timestamp and timezone, client location, exact URL, request count, whether requests are sequential/concurrent, timeout, status/exit results and software/configuration versions. Note whether the response came from a CDN/cache or the origin if you have verified that distinction.

Repeat from the same client using the same workload when comparing a tuning change. Also test the actual user workflow: anonymous content, logged-in pages, search and writes can have very different costs. Do not combine those outcomes into one unexplained average.

6. Choose the next investigation from evidence

• PHP worker queues or saturation: inspect PHP-FPM status/slow logs and memory per worker before choosing pm.max_children.
  
• Database-heavy requests: inspect slow queries, query plans, indexes and connection behavior before increasing SQL limits.
  
• Repeated anonymous content: evaluate page caching with appropriate exclusions for private or changing content.
  
• High I/O wait: investigate storage and query/file access rather than assuming more PHP workers will help.
  
• Slow assets/rendering: measure browser/frontend behavior; an origin response test alone cannot explain it.
  

A worker limit should account for measured application memory use and RAM reserved for the database, operating system and other services. A database buffer setting must fit the real shared workload. Raising every limit can increase memory pressure instead of throughput.

7. Plan a controlled comparison
Back up the exact configuration before editing it. Change one meaningful setting at a time, validate configuration, repeat the same test and compare latency, error rate and resource use. Define rollback conditions before applying changes.

A later controlled load test should use an authorized lab target, bounded duration and concurrency, realistic requests and clear stop conditions. Do not infer requests-per-second capacity or supported monthly visitors from the small sequential sample in this guide.

What this guide verified
Two lab URLs each returned HTTP 200 for ten sequential client requests. We recorded client response timings and a server-resource snapshot. No PHP, database or Nginx tuning, stress test or production configuration change was performed.

AdminsForum performance series, lesson 1: baseline measurement. Later lessons will compare specific changes against documented workloads.]]> https://adminsforum.com/Thread-guide-check-nginx-php-fpm-and-mysql-services-in-aapanel-via-ssh Wed, 14 Oct 2026 18:14:41 +0800 DEV]]> https://adminsforum.com/Thread-guide-check-nginx-php-fpm-and-mysql-services-in-aapanel-via-ssh When a website fails, check the service that handles the failing request. aaPanel-installed Nginx, PHP-FPM and database services can have different names and paths from distribution packages. Inspect the installed service before copying a generic command.

Tested lab: Ubuntu 22.04.5 and aaPanel Free 8.0.7. We checked Nginx, MariaDB under the mysqld service name, and PHP-FPM 8.4/8.5. Nginx and both PHP-FPM configuration tests passed. This lesson tested diagnostic commands without restarting those services.


  service-cli-transcript-20261014.jpg (Size: 112.3 KB / Downloads: 5)
Formatted transcript summarizing actual status and configuration-test results from our lab.

1. Know which component you are checking

• aaPanel: management dashboard, checked with bt status.
  
• Nginx: handles website requests and proxies dynamic work.
  
• PHP-FPM: executes PHP for sites configured to use that PHP version.
  
• MySQL/MariaDB: stores database data; a running database process does not prove an application's credentials work.
  

Restarting aaPanel does not mean you restarted the website stack. Start with the bt CLI overview for panel-specific commands.

2. Find the installed service names
From an authorized SSH administrator session:

Code:Copy

ls /etc/init.d/nginx /etc/init.d/mysqld /etc/init.d/php-fpm-*

Our lab had nginx, mysqld, php-fpm-84 and php-fpm-85. If your server uses Apache, another PHP version or a different database setup, inspect those actual names rather than assuming these apply. Missing paths are a reason to verify installation, not to reinstall the server stack blindly.

3. Check Nginx and validate configuration

Code:Copy

/etc/init.d/nginx status /www/server/nginx/sbin/nginx -t

The lab's status reported Nginx running. The syntax test reported that /www/server/nginx/conf/nginx.conf was valid and the test was successful.

A syntax test does not prove the site serves the right content. After a configuration change, check a real HTTP/HTTPS request as well. If validation fails, correct the reported file and line before reloading. Keep a backup of the changed configuration.

Reload versus restart
For a reviewed Nginx configuration change, a reload asks the running server to load the new configuration. A restart stops and starts the service and can interrupt requests. The installed init script supports service controls, but this guide did not execute a reload or restart:

Code:Copy

/etc/init.d/nginx reload /etc/init.d/nginx restart

These are operational examples, not commands to run merely because you are reading this guide. Validate first and choose the action that the maintenance requires.

4. Check the website's PHP-FPM version
Confirm the PHP version selected for the website in aaPanel. Our lab has two separate services:

Code:Copy

/etc/init.d/php-fpm-84 status /etc/init.d/php-fpm-85 status

Both reported running. Version-specific configuration tests were:

Code:Copy

/www/server/php/84/sbin/php-fpm -t /www/server/php/85/sbin/php-fpm -t

Both passed. Use the matching path for your installed version. Restarting 8.4 will not repair a site served by 8.5.

If maintenance genuinely requires restarting the website's PHP-FPM service, its installed service script provides the restart action. For example:

Code:Copy

/etc/init.d/php-fpm-85 restart

We did not execute that restart in this lesson. It can affect every site using that PHP-FPM version. Afterwards check service status, recent logs and a meaningful PHP request.

The shell's php --version can identify a CLI default rather than the PHP-FPM version handling a specific website. Do not use it as the only evidence of the site's runtime.

5. Check MySQL or MariaDB

Code:Copy

/etc/init.d/mysqld status

Our status output identified MariaDB and active (running), despite the service script being named mysqld. Both naming and installed implementation matter when interpreting commands.

A database restart can interrupt applications and active connections. Do not restart it as the first response to an authentication or missing-table error. Confirm the actual failure and plan maintenance before using a control action such as:

Code:Copy

/etc/init.d/mysqld restart

This restart was not executed for the lesson. Before database maintenance, preserve an appropriate backup and recovery plan. Afterwards verify service readiness and an application connection through its normal secure configuration; do not put database passwords into public command examples.

6. Verify the website beyond status
A running process is one signal, not the whole result. Check:

• The intended service and PHP version.
  
• Configuration validation after edits.
  
• The hostname's response with normal certificate validation.
  
• A dynamic application action and database connection where relevant.
  
• Recent relevant errors rather than old log entries.
  

For example, a PHP site can still return 502 when Nginx is running but its configured PHP-FPM socket is wrong. A site can connect to the web server but fail inside the application because its database credentials are incorrect.

Common mistakes

• Using system package paths for software installed under /www/server.
  
• Restarting every service instead of diagnosing the failing component.
  
• Checking the CLI PHP version instead of the website's configured PHP-FPM version.
  
• Treating mysqld as proof that the database implementation must be MySQL.
  
• Reloading invalid configuration or assuming a successful syntax test proves application health.
  
• Posting raw logs that contain tokens or database credentials.
  

What our lab verified
Nginx was running and passed its configuration test. MariaDB's mysqld service was active. Both PHP-FPM 8.4 and 8.5 were running and passed configuration tests. Service restart examples were explained, not executed or claimed as tested.

AdminsForum CLI series. The image is a formatted lab-result transcript; use the service names and paths actually installed on your own server.]]> When a website fails, check the service that handles the failing request. aaPanel-installed Nginx, PHP-FPM and database services can have different names and paths from distribution packages. Inspect the installed service before copying a generic command.

Tested lab: Ubuntu 22.04.5 and aaPanel Free 8.0.7. We checked Nginx, MariaDB under the mysqld service name, and PHP-FPM 8.4/8.5. Nginx and both PHP-FPM configuration tests passed. This lesson tested diagnostic commands without restarting those services.


  service-cli-transcript-20261014.jpg (Size: 112.3 KB / Downloads: 5)
Formatted transcript summarizing actual status and configuration-test results from our lab.

1. Know which component you are checking

• aaPanel: management dashboard, checked with bt status.
  
• Nginx: handles website requests and proxies dynamic work.
  
• PHP-FPM: executes PHP for sites configured to use that PHP version.
  
• MySQL/MariaDB: stores database data; a running database process does not prove an application's credentials work.
  

Restarting aaPanel does not mean you restarted the website stack. Start with the bt CLI overview for panel-specific commands.

2. Find the installed service names
From an authorized SSH administrator session:

Code:Copy

ls /etc/init.d/nginx /etc/init.d/mysqld /etc/init.d/php-fpm-*

Our lab had nginx, mysqld, php-fpm-84 and php-fpm-85. If your server uses Apache, another PHP version or a different database setup, inspect those actual names rather than assuming these apply. Missing paths are a reason to verify installation, not to reinstall the server stack blindly.

3. Check Nginx and validate configuration

Code:Copy

/etc/init.d/nginx status /www/server/nginx/sbin/nginx -t

The lab's status reported Nginx running. The syntax test reported that /www/server/nginx/conf/nginx.conf was valid and the test was successful.

A syntax test does not prove the site serves the right content. After a configuration change, check a real HTTP/HTTPS request as well. If validation fails, correct the reported file and line before reloading. Keep a backup of the changed configuration.

Reload versus restart
For a reviewed Nginx configuration change, a reload asks the running server to load the new configuration. A restart stops and starts the service and can interrupt requests. The installed init script supports service controls, but this guide did not execute a reload or restart:

Code:Copy

/etc/init.d/nginx reload /etc/init.d/nginx restart

These are operational examples, not commands to run merely because you are reading this guide. Validate first and choose the action that the maintenance requires.

4. Check the website's PHP-FPM version
Confirm the PHP version selected for the website in aaPanel. Our lab has two separate services:

Code:Copy

/etc/init.d/php-fpm-84 status /etc/init.d/php-fpm-85 status

Both reported running. Version-specific configuration tests were:

Code:Copy

/www/server/php/84/sbin/php-fpm -t /www/server/php/85/sbin/php-fpm -t

Both passed. Use the matching path for your installed version. Restarting 8.4 will not repair a site served by 8.5.

If maintenance genuinely requires restarting the website's PHP-FPM service, its installed service script provides the restart action. For example:

Code:Copy

/etc/init.d/php-fpm-85 restart

We did not execute that restart in this lesson. It can affect every site using that PHP-FPM version. Afterwards check service status, recent logs and a meaningful PHP request.

The shell's php --version can identify a CLI default rather than the PHP-FPM version handling a specific website. Do not use it as the only evidence of the site's runtime.

5. Check MySQL or MariaDB

Code:Copy

/etc/init.d/mysqld status

Our status output identified MariaDB and active (running), despite the service script being named mysqld. Both naming and installed implementation matter when interpreting commands.

A database restart can interrupt applications and active connections. Do not restart it as the first response to an authentication or missing-table error. Confirm the actual failure and plan maintenance before using a control action such as:

Code:Copy

/etc/init.d/mysqld restart

This restart was not executed for the lesson. Before database maintenance, preserve an appropriate backup and recovery plan. Afterwards verify service readiness and an application connection through its normal secure configuration; do not put database passwords into public command examples.

6. Verify the website beyond status
A running process is one signal, not the whole result. Check:

• The intended service and PHP version.
  
• Configuration validation after edits.
  
• The hostname's response with normal certificate validation.
  
• A dynamic application action and database connection where relevant.
  
• Recent relevant errors rather than old log entries.
  

For example, a PHP site can still return 502 when Nginx is running but its configured PHP-FPM socket is wrong. A site can connect to the web server but fail inside the application because its database credentials are incorrect.

Common mistakes

• Using system package paths for software installed under /www/server.
  
• Restarting every service instead of diagnosing the failing component.
  
• Checking the CLI PHP version instead of the website's configured PHP-FPM version.
  
• Treating mysqld as proof that the database implementation must be MySQL.
  
• Reloading invalid configuration or assuming a successful syntax test proves application health.
  
• Posting raw logs that contain tokens or database credentials.
  

What our lab verified
Nginx was running and passed its configuration test. MariaDB's mysqld service was active. Both PHP-FPM 8.4 and 8.5 were running and passed configuration tests. Service restart examples were explained, not executed or claimed as tested.

AdminsForum CLI series. The image is a formatted lab-result transcript; use the service names and paths actually installed on your own server.]]> https://adminsforum.com/Thread-guide-manage-python-packages-with-requirements-txt-in-aapanel Wed, 14 Oct 2026 15:13:52 +0800 DEV]]> https://adminsforum.com/Thread-guide-manage-python-packages-with-requirements-txt-in-aapanel requirements.txt records the Python packages an application needs, so you can install them into the correct environment and rebuild the app later. In aaPanel, the key is using the Python executable from the environment selected for that project.

Tested: Our Flask project on aaPanel Free 8.0.7 uses af_python_lab. We also created a separate clean environment, installed the sample's requirements, ran pip check and started the restored app on a different local port. This lesson uses SSH commands for package management; it does not claim a new aaPanel package-management screen exists.


  python-requirements-workflow-20261014.jpg (Size: 107.06 KB / Downloads: 5)
Dependency workflow diagram: record, install, check and run the application.

1. Find the project's actual environment
Open Website → Python Project, click the project and inspect Project information → Python Environment. Our selected environment is af_python_lab. Its actual path on this panel version is:

Code:Copy

/www/server/pyporject_evn/af_python_lab

Do not assume the path is identical on every release. Verify the executable before installing packages:

Code:Copy

/www/server/pyporject_evn/af_python_lab/bin/python --version /www/server/pyporject_evn/af_python_lab/bin/python -m pip --version

The pip output should point inside that environment. Using python -m pip ties the installer to the chosen interpreter, avoiding a different pip from the shell's PATH.

2. Create requirements.txt beside the app
For our small sample, the project folder is /www/wwwroot/af-flask-lab and the file contains:

Code:Copy

Flask==3.1.3 gunicorn==26.2.0

Each line names a package; == pins the direct version. These are the versions tested in this lab, not an instruction to upgrade every existing app to them. Use your application's known compatible versions and include its real direct dependencies.

This two-line file does not pin every transitive dependency. Pip will resolve Flask's dependencies when it installs the file. For stronger repeatability, keep a reviewed full version snapshot or the lock file used by your project's dependency workflow.

3. Understand pip freeze before using it
To inspect installed packages in this environment:

Code:Copy

/www/server/pyporject_evn/af_python_lab/bin/python -m pip list /www/server/pyporject_evn/af_python_lab/bin/python -m pip freeze

A freeze snapshot includes installed packages, including packages added by tools or unrelated experiments in that same environment. It does not identify which ones your application directly uses. Review it before using it as your application requirements file, and avoid overwriting an existing reviewed file without keeping a copy.

AaPanel initialized additional support packages in our project environment. For the tiny Flask restore, we used the application's two direct dependencies instead of blindly copying every installed package.

4. Install using the intended environment and user
If the environment belongs to www, run the installer as that user. Give it a writable cache inside the project rather than broadening permissions on system directories:

Code:Copy

runuser -u www -- /www/server/pyporject_evn/af_python_lab/bin/python  -m pip install --cache-dir /www/wwwroot/af-flask-lab/.pip-cache  -r /www/wwwroot/af-flask-lab/requirements.txt

The project and environment must already have appropriate ownership for www. If the command reports Permission denied, inspect that specific path; do not apply chmod 777 to the environment or the whole website tree.

Review the requirements file and package source before installation. Do not paste credentials into package URLs that may appear in shell history or logs. For a running application, rehearse dependency changes in a separate environment and plan rollback before changing its live packages.

5. Check consistency and run the app
Use the same interpreter:

Code:Copy

/www/server/pyporject_evn/af_python_lab/bin/python -m pip check /www/server/pyporject_evn/af_python_lab/bin/python -m pip show Flask gunicorn

A successful pip check reports no incompatible or missing declared package requirements. It does not prove your application behavior is correct, so also test startup and a meaningful application request.

6. Prove the file can rebuild a clean environment
Our recovery exercise created a new environment under /www/af-flask-restore-20261014/venv and installed:

Code:Copy

/www/af-flask-restore-20261014/venv/bin/python -m pip install  -r /www/af-flask-restore-20261014/af-flask-lab/requirements.txt /www/af-flask-restore-20261014/venv/bin/python -m pip check

The installation succeeded with Flask 3.1.3 and Gunicorn 26.2.0. Pip check reported No broken requirements found. The rebuilt app returned HTTP 200 and AdminsForum Flask lab on 127.0.0.1:3202, then the temporary test process was stopped. The live website still returned HTTP 200.

See Back Up and Restore a Flask App for the complete isolated test. A separate environment prevents a failed experiment from replacing the live application's dependencies.

Common errors

• No module named flask: verify the project uses the same environment in which you installed Flask.
  
• No matching distribution: check whether the requested package version supports your Python version and platform.
  
• Permission denied: check the installer user, environment ownership and cache directory.
  
• Dependency conflict: read the reported package versions; test compatible pins in a clean environment rather than forcing an inconsistent installation.
  
• Packages install but app fails: check the startup command, environment variables, OS libraries and application logs. Pip cannot configure those for you.
  

Completion checklist

• Correct project environment identified.
  
• Application dependency file reviewed and backed up.
  
• Install and verification use the same interpreter.
  
• Pip check passes.
  
• Clean-environment rebuild and application response tested.
  

Reference: Official pip requirements-file documentation and pip freeze documentation.

Tested and illustrated by AdminsForum. Diagram summarizes our lab workflow; use paths and versions appropriate to your application.]]> requirements.txt records the Python packages an application needs, so you can install them into the correct environment and rebuild the app later. In aaPanel, the key is using the Python executable from the environment selected for that project.

Tested: Our Flask project on aaPanel Free 8.0.7 uses af_python_lab. We also created a separate clean environment, installed the sample's requirements, ran pip check and started the restored app on a different local port. This lesson uses SSH commands for package management; it does not claim a new aaPanel package-management screen exists.


  python-requirements-workflow-20261014.jpg (Size: 107.06 KB / Downloads: 5)
Dependency workflow diagram: record, install, check and run the application.

1. Find the project's actual environment
Open Website → Python Project, click the project and inspect Project information → Python Environment. Our selected environment is af_python_lab. Its actual path on this panel version is:

Code:Copy

/www/server/pyporject_evn/af_python_lab

Do not assume the path is identical on every release. Verify the executable before installing packages:

Code:Copy

/www/server/pyporject_evn/af_python_lab/bin/python --version /www/server/pyporject_evn/af_python_lab/bin/python -m pip --version

The pip output should point inside that environment. Using python -m pip ties the installer to the chosen interpreter, avoiding a different pip from the shell's PATH.

2. Create requirements.txt beside the app
For our small sample, the project folder is /www/wwwroot/af-flask-lab and the file contains:

Code:Copy

Flask==3.1.3 gunicorn==26.2.0

Each line names a package; == pins the direct version. These are the versions tested in this lab, not an instruction to upgrade every existing app to them. Use your application's known compatible versions and include its real direct dependencies.

This two-line file does not pin every transitive dependency. Pip will resolve Flask's dependencies when it installs the file. For stronger repeatability, keep a reviewed full version snapshot or the lock file used by your project's dependency workflow.

3. Understand pip freeze before using it
To inspect installed packages in this environment:

Code:Copy

/www/server/pyporject_evn/af_python_lab/bin/python -m pip list /www/server/pyporject_evn/af_python_lab/bin/python -m pip freeze

A freeze snapshot includes installed packages, including packages added by tools or unrelated experiments in that same environment. It does not identify which ones your application directly uses. Review it before using it as your application requirements file, and avoid overwriting an existing reviewed file without keeping a copy.

AaPanel initialized additional support packages in our project environment. For the tiny Flask restore, we used the application's two direct dependencies instead of blindly copying every installed package.

4. Install using the intended environment and user
If the environment belongs to www, run the installer as that user. Give it a writable cache inside the project rather than broadening permissions on system directories:

Code:Copy

runuser -u www -- /www/server/pyporject_evn/af_python_lab/bin/python  -m pip install --cache-dir /www/wwwroot/af-flask-lab/.pip-cache  -r /www/wwwroot/af-flask-lab/requirements.txt

The project and environment must already have appropriate ownership for www. If the command reports Permission denied, inspect that specific path; do not apply chmod 777 to the environment or the whole website tree.

Review the requirements file and package source before installation. Do not paste credentials into package URLs that may appear in shell history or logs. For a running application, rehearse dependency changes in a separate environment and plan rollback before changing its live packages.

5. Check consistency and run the app
Use the same interpreter:

Code:Copy

/www/server/pyporject_evn/af_python_lab/bin/python -m pip check /www/server/pyporject_evn/af_python_lab/bin/python -m pip show Flask gunicorn

A successful pip check reports no incompatible or missing declared package requirements. It does not prove your application behavior is correct, so also test startup and a meaningful application request.

6. Prove the file can rebuild a clean environment
Our recovery exercise created a new environment under /www/af-flask-restore-20261014/venv and installed:

Code:Copy

/www/af-flask-restore-20261014/venv/bin/python -m pip install  -r /www/af-flask-restore-20261014/af-flask-lab/requirements.txt /www/af-flask-restore-20261014/venv/bin/python -m pip check

The installation succeeded with Flask 3.1.3 and Gunicorn 26.2.0. Pip check reported No broken requirements found. The rebuilt app returned HTTP 200 and AdminsForum Flask lab on 127.0.0.1:3202, then the temporary test process was stopped. The live website still returned HTTP 200.

See Back Up and Restore a Flask App for the complete isolated test. A separate environment prevents a failed experiment from replacing the live application's dependencies.

Common errors

• No module named flask: verify the project uses the same environment in which you installed Flask.
  
• No matching distribution: check whether the requested package version supports your Python version and platform.
  
• Permission denied: check the installer user, environment ownership and cache directory.
  
• Dependency conflict: read the reported package versions; test compatible pins in a clean environment rather than forcing an inconsistent installation.
  
• Packages install but app fails: check the startup command, environment variables, OS libraries and application logs. Pip cannot configure those for you.
  

Completion checklist

• Correct project environment identified.
  
• Application dependency file reviewed and backed up.
  
• Install and verification use the same interpreter.
  
• Pip check passes.
  
• Clean-environment rebuild and application response tested.
  

Reference: Official pip requirements-file documentation and pip freeze documentation.

Tested and illustrated by AdminsForum. Diagram summarizes our lab workflow; use paths and versions appropriate to your application.]]> https://adminsforum.com/Thread-guide-auto-start-python-and-flask-apps-after-reboot-in-aapanel Wed, 14 Oct 2026 15:06:48 +0800 DEV]]> https://adminsforum.com/Thread-guide-auto-start-python-and-flask-apps-after-reboot-in-aapanel A Python project that works today can remain offline after a VPS reboot unless its startup setting is enabled. This guide enables aaPanel's native recovery option and verifies that a Flask app actually returns after a real reboot.

Tested: Ubuntu 22.04.5 and aaPanel Free 8.0.7, with Flask served by Gunicorn through Nginx. Our project is af_flask_lab and listens on 127.0.0.1:3200. Replace these values with your own project. A reboot temporarily interrupts every service on that VPS; use a lab or a planned maintenance window.

1. Confirm the app is healthy first
Complete Run Flask with Gunicorn and, if you need a public hostname, Connect Flask to a Domain and HTTPS.

Open Website → Python Project and confirm the application is running. From the VPS terminal:

Code:Copy

curl -i http://127.0.0.1:3200/

You should receive HTTP 200 and your expected application response. Resolve startup errors before testing reboot recovery.

2. Enable aaPanel's Startup option
Click the project name, then open Project information. Locate Startup and tick the checkbox labelled default built-in daemon checks every 120 seconds. Click Save.


  python-startup-20261014.jpg (Size: 145.33 KB / Downloads: 4)
Enable the native Startup checkbox for the correct Python project, then save its settings.

This setting tells aaPanel to recover the project when its daemon finds it stopped. It is not an immediate availability guarantee: the panel advertises a 120-second check interval. Keep the same working startup command, environment, project path and non-root user.

Our command remained:

Code:Copy

gunicorn --workers 1 --bind 127.0.0.1:3200 app:app

The selected environment was af_python_lab and the startup user was www. Do not create a second systemd or cron launcher for the same process while using the native panel daemon; two launchers can compete for the same port.

3. Recheck HTTP and HTTPS after saving
Before rebooting, check localhost and the public hostname again. In our aaPanel 8.0.7 lab, saving the Python project settings regenerated its Nginx configuration and removed the 443 SSL listener. The app still worked on localhost, but public HTTPS selected another site's certificate and failed hostname validation.

This is a separate configuration problem, not proof that Gunicorn failed. Check SSL and the project's Nginx Config after saving. Back up the configuration before editing it. For this lab we restored the HTTPS listener and the existing certificate references, validated Nginx configuration and reloaded Nginx. We did not issue another certificate.

The existing certificate paths in this lab were:

Code:Copy

/www/server/panel/vhost/cert/af_flask_lab/fullchain.pem /www/server/panel/vhost/cert/af_flask_lab/privkey.pem

Your project may have different paths. Do not copy another site's certificate or publish private-key contents. Normal HTTPS validation must pass; do not hide the error with curl -k.

4. Record the current boot before rebooting
From the VPS terminal:

Code:Copy

cat /proc/sys/kernel/random/boot_id

Keep this value locally. After the reboot it must differ, proving you tested a new server boot rather than a simple browser refresh.

Reboot only after your work is saved and you have a working way to reconnect. In a disposable test VPS, a normal reboot command is:

Code:Copy

sudo reboot

An SSH disconnection is expected while the server restarts. A browser tab can also lose its aaPanel session; signing back into the panel is separate from restarting the application.

5. Verify recovery without manually starting the app
Reconnect through SSH after the VPS is reachable. Check:

Code:Copy

cat /proc/sys/kernel/random/boot_id ss -lntp | grep ':3200' curl -i http://127.0.0.1:3200/ curl -i https://your-hostname/

Wait for the native daemon's recovery interval if the application has not returned yet. Do not click Start during the automatic recovery test, because that would invalidate the test.

Our new boot ID differed from the original. Gunicorn returned automatically with a master and worker listening on 127.0.0.1:3200. After restoring the SSL listener described above, the public Flask hostname returned HTTP 200 with AdminsForum Flask lab and passed certificate validation. Nginx, Postfix and Dovecot were also active.

6. Inspect logs if recovery fails
In the project window, open Project logs. Check the latest startup attempt rather than old messages. For this project, the error log was:

Code:Copy

/www/wwwlogs/python/af_flask_lab/error.log

Typical problems include a missing virtual environment, incorrect working directory, missing packages, a port already in use or a startup user unable to read the app files. Confirm that the same command still starts the app in its intended environment before changing the daemon.

Know the limits of this test

• A successful reboot test confirms recovery for the tested app and configuration. It does not test database recovery, queues, upload persistence or every application dependency.
  
• Startup recovery can cause a short period of 502 responses while Nginx is running but Gunicorn has not started yet.
  
• Because the native daemon recovers stopped projects, temporarily disable Startup when deliberately keeping an app stopped for maintenance; restore it when the maintenance is finished.
  
• Repeat HTTP and HTTPS checks after later project edits. The SSL configuration issue above was observed on this lab version, not assumed for every aaPanel release.
  

Completion checklist

• Startup checkbox enabled and saved.
  
• Correct environment, project path and non-root user retained.
  
• A real reboot confirmed by a changed boot ID.
  
• App returned without a manual Start action.
  
• Local response, public mapping and HTTPS checked separately.
  
• Any recovery errors explained using current logs.
  

Tested on the AdminsForum lab VPS. Screenshot and test results are from our own deployment.]]> A Python project that works today can remain offline after a VPS reboot unless its startup setting is enabled. This guide enables aaPanel's native recovery option and verifies that a Flask app actually returns after a real reboot.

Tested: Ubuntu 22.04.5 and aaPanel Free 8.0.7, with Flask served by Gunicorn through Nginx. Our project is af_flask_lab and listens on 127.0.0.1:3200. Replace these values with your own project. A reboot temporarily interrupts every service on that VPS; use a lab or a planned maintenance window.

1. Confirm the app is healthy first
Complete Run Flask with Gunicorn and, if you need a public hostname, Connect Flask to a Domain and HTTPS.

Open Website → Python Project and confirm the application is running. From the VPS terminal:

Code:Copy

curl -i http://127.0.0.1:3200/

You should receive HTTP 200 and your expected application response. Resolve startup errors before testing reboot recovery.

2. Enable aaPanel's Startup option
Click the project name, then open Project information. Locate Startup and tick the checkbox labelled default built-in daemon checks every 120 seconds. Click Save.


  python-startup-20261014.jpg (Size: 145.33 KB / Downloads: 4)
Enable the native Startup checkbox for the correct Python project, then save its settings.

This setting tells aaPanel to recover the project when its daemon finds it stopped. It is not an immediate availability guarantee: the panel advertises a 120-second check interval. Keep the same working startup command, environment, project path and non-root user.

Our command remained:

Code:Copy

gunicorn --workers 1 --bind 127.0.0.1:3200 app:app

The selected environment was af_python_lab and the startup user was www. Do not create a second systemd or cron launcher for the same process while using the native panel daemon; two launchers can compete for the same port.

3. Recheck HTTP and HTTPS after saving
Before rebooting, check localhost and the public hostname again. In our aaPanel 8.0.7 lab, saving the Python project settings regenerated its Nginx configuration and removed the 443 SSL listener. The app still worked on localhost, but public HTTPS selected another site's certificate and failed hostname validation.

This is a separate configuration problem, not proof that Gunicorn failed. Check SSL and the project's Nginx Config after saving. Back up the configuration before editing it. For this lab we restored the HTTPS listener and the existing certificate references, validated Nginx configuration and reloaded Nginx. We did not issue another certificate.

The existing certificate paths in this lab were:

Code:Copy

/www/server/panel/vhost/cert/af_flask_lab/fullchain.pem /www/server/panel/vhost/cert/af_flask_lab/privkey.pem

Your project may have different paths. Do not copy another site's certificate or publish private-key contents. Normal HTTPS validation must pass; do not hide the error with curl -k.

4. Record the current boot before rebooting
From the VPS terminal:

Code:Copy

cat /proc/sys/kernel/random/boot_id

Keep this value locally. After the reboot it must differ, proving you tested a new server boot rather than a simple browser refresh.

Reboot only after your work is saved and you have a working way to reconnect. In a disposable test VPS, a normal reboot command is:

Code:Copy

sudo reboot

An SSH disconnection is expected while the server restarts. A browser tab can also lose its aaPanel session; signing back into the panel is separate from restarting the application.

5. Verify recovery without manually starting the app
Reconnect through SSH after the VPS is reachable. Check:

Code:Copy

cat /proc/sys/kernel/random/boot_id ss -lntp | grep ':3200' curl -i http://127.0.0.1:3200/ curl -i https://your-hostname/

Wait for the native daemon's recovery interval if the application has not returned yet. Do not click Start during the automatic recovery test, because that would invalidate the test.

Our new boot ID differed from the original. Gunicorn returned automatically with a master and worker listening on 127.0.0.1:3200. After restoring the SSL listener described above, the public Flask hostname returned HTTP 200 with AdminsForum Flask lab and passed certificate validation. Nginx, Postfix and Dovecot were also active.

6. Inspect logs if recovery fails
In the project window, open Project logs. Check the latest startup attempt rather than old messages. For this project, the error log was:

Code:Copy

/www/wwwlogs/python/af_flask_lab/error.log

Typical problems include a missing virtual environment, incorrect working directory, missing packages, a port already in use or a startup user unable to read the app files. Confirm that the same command still starts the app in its intended environment before changing the daemon.

Know the limits of this test

• A successful reboot test confirms recovery for the tested app and configuration. It does not test database recovery, queues, upload persistence or every application dependency.
  
• Startup recovery can cause a short period of 502 responses while Nginx is running but Gunicorn has not started yet.
  
• Because the native daemon recovers stopped projects, temporarily disable Startup when deliberately keeping an app stopped for maintenance; restore it when the maintenance is finished.
  
• Repeat HTTP and HTTPS checks after later project edits. The SSL configuration issue above was observed on this lab version, not assumed for every aaPanel release.
  

Completion checklist

• Startup checkbox enabled and saved.
  
• Correct environment, project path and non-root user retained.
  
• A real reboot confirmed by a changed boot ID.
  
• App returned without a manual Start action.
  
• Local response, public mapping and HTTPS checked separately.
  
• Any recovery errors explained using current logs.
  

Tested on the AdminsForum lab VPS. Screenshot and test results are from our own deployment.]]> https://adminsforum.com/Thread-guide-connect-a-flask-app-to-a-domain-and-https-in-aapanel Wed, 14 Oct 2026 14:34:55 +0800 DEV]]> https://adminsforum.com/Thread-guide-connect-a-flask-app-to-a-domain-and-https-in-aapanel A Flask app can work on localhost while still being unavailable through its domain. This guide connects a running Gunicorn project to Nginx, points a hostname at the VPS and enables HTTPS with a trusted certificate.

Tested lab: Ubuntu 22.04.5, aaPanel Free 8.0.7, Nginx 1.30.5, Flask 3.1.3 and Gunicorn 26.2.0. The public test hostname is flask.adminslab.com. Replace the hostname and VPS address with your own values. Menu wording can vary by panel version.

Before you start

• Complete Run a Flask App with Gunicorn in aaPanel. This lesson assumes the Python project is already running.
  
• Have control of the domain's DNS. Nginx must be installed and the VPS must accept incoming TCP 80 and 443 through both its server firewall and any provider firewall.
  
• The application should listen on localhost, not a public interface. Our Gunicorn command is:
  

Code:Copy

gunicorn --workers 1 --bind 127.0.0.1:3200 app:app

Port 3200 is the private application port. Visitors use 80 or 443 through Nginx; you do not need to open 3200 to the Internet.

1. Check the application before changing DNS
In aaPanel, open Website → Python Project. Check that your project is running. Our project is af_flask_lab. If it does not start, open Project logs and fix the startup error first.

From the VPS terminal, test:

Code:Copy

curl -i http://127.0.0.1:3200/

Our test returned HTTP 200 and the body AdminsForum Flask lab. If this fails, a certificate or DNS change will not repair the application itself.

2. Add the domain to the Python project
Click the project name to open its management window. Select Domain Manager, enter your full hostname (for example, flask.example.com) without https:// or a path, and add it on port 80. Confirm that the domain appears in the project's domain list.

Do not create a separate PHP website with the same hostname. The Python project should own the hostname so Nginx sends requests to the correct application.

3. Point the DNS record at the VPS
If the domain uses Cloudflare nameservers, open the domain in Cloudflare and choose DNS → Records → Add record. For our subdomain we used:

• Type: A
  
• Name: flask
  
• IPv4 address: the lab VPS public IPv4 address
  
• Proxy status: DNS only for this direct-origin certificate test
  
• TTL: Auto
  

Save the record. Check for conflicting records for the same hostname. An AAAA record must point to a working IPv6 origin; do not leave an incorrect IPv6 record in place.

DNS only makes the hostname resolve directly to the VPS. This guide tests Nginx and its certificate at the origin; Cloudflare proxy configuration is a separate step. Allow DNS propagation before requesting the certificate.

4. Enable external network mapping
Return to the project's Mapping section. Turn on External network mapping and confirm the panel's prompt. The panel should detect the running application port. In our lab it detected 3200 and showed Proxy routing is enabled: /.


  flask-mapping-20261014.jpg (Size: 227.67 KB / Downloads: 4)
The Python project's mapping routes website traffic through Nginx to the local application port.

The Firewall Status: Not configured entry for 3200 does not mean you must expose that port. The browser reaches Nginx on 80/443, and Nginx reaches Gunicorn on 127.0.0.1:3200.

Open http://your-hostname/ and check that it displays your Flask response. Our public HTTP check returned HTTP 200. If you see another website, check domain ownership and DNS. If you see 502, check the running process, its bind address and the mapping port.

5. Apply a Let's Encrypt certificate
In the project's management window, open SSL → Let's Encrypt. Choose File Verification, select the exact hostname and click Apply. File verification requires the certificate authority to reach the hostname on port 80.


  flask-ssl-request-20261014.jpg (Size: 161.76 KB / Downloads: 4)
Select only the hostname that resolves to this project before applying for its certificate.

Some panel versions display Not connected to the Domain Management Center and a Connect action. Review that integration before connecting your domain, then return to the certificate request. Wait for issuance to finish; a pending request is not an installed certificate.

In this lab, the SSL section changed to Current Certs — Deployed, listed flask.adminslab.com and showed an expiry date of 12 January 2027. We also validated the live certificate independently. Do not copy or share the private-key field from the certificate screen.

6. Verify HTTPS from outside the VPS
Open https://your-hostname/ in a browser. The page must display the expected application without a certificate warning. From a terminal, you can also test:

Code:Copy

curl -i https://your-hostname/

Do not use curl -k for this check: it skips certificate validation and can hide a broken certificate.


  flask-https-result-20261014.jpg (Size: 27.6 KB / Downloads: 4)
The public HTTPS hostname serves the expected Flask lab response.

Our result: https://flask.adminslab.com/ returned HTTP 200 with AdminsForum Flask lab, and certificate validation passed. This confirms DNS, Nginx mapping, the running application and HTTPS worked together at the time of testing.

Troubleshooting

• DNS points to the wrong server: correct the A record and any conflicting AAAA record, then allow caches to expire.
  
• HTTP works but certificate verification fails: check port 80, redirects, proxy rules and whether the selected hostname is the one attached to this project. Read the issuance error rather than repeatedly submitting requests.
  
• HTTPS shows another site's certificate: confirm this hostname has its own deployed certificate and is served by the expected Nginx project.
  
• 502 Bad Gateway: verify localhost responds, then compare the Gunicorn port with the mapping port and inspect Project logs.
  
• App stops after reboot: this guide does not verify Python reboot recovery. Test and document autostart separately before treating the deployment as production-ready.
  

Completion checklist

• Domain is listed under the correct Python project.
  
• DNS resolves to the intended VPS.
  
• Local Gunicorn and public HTTP both return the expected content.
  
• Mapping uses the application's local port.
  
• SSL is deployed for the exact hostname.
  
• Public HTTPS passes normal certificate validation and returns the expected app.
  

Related: Create a Python Virtual Environment · Run Flask with Gunicorn

Tested and illustrated by AdminsForum. Screenshots show our own lab; use your own domain and application values.]]> A Flask app can work on localhost while still being unavailable through its domain. This guide connects a running Gunicorn project to Nginx, points a hostname at the VPS and enables HTTPS with a trusted certificate.

Tested lab: Ubuntu 22.04.5, aaPanel Free 8.0.7, Nginx 1.30.5, Flask 3.1.3 and Gunicorn 26.2.0. The public test hostname is flask.adminslab.com. Replace the hostname and VPS address with your own values. Menu wording can vary by panel version.

Before you start

• Complete Run a Flask App with Gunicorn in aaPanel. This lesson assumes the Python project is already running.
  
• Have control of the domain's DNS. Nginx must be installed and the VPS must accept incoming TCP 80 and 443 through both its server firewall and any provider firewall.
  
• The application should listen on localhost, not a public interface. Our Gunicorn command is:
  

Code:Copy

gunicorn --workers 1 --bind 127.0.0.1:3200 app:app

Port 3200 is the private application port. Visitors use 80 or 443 through Nginx; you do not need to open 3200 to the Internet.

1. Check the application before changing DNS
In aaPanel, open Website → Python Project. Check that your project is running. Our project is af_flask_lab. If it does not start, open Project logs and fix the startup error first.

From the VPS terminal, test:

Code:Copy

curl -i http://127.0.0.1:3200/

Our test returned HTTP 200 and the body AdminsForum Flask lab. If this fails, a certificate or DNS change will not repair the application itself.

2. Add the domain to the Python project
Click the project name to open its management window. Select Domain Manager, enter your full hostname (for example, flask.example.com) without https:// or a path, and add it on port 80. Confirm that the domain appears in the project's domain list.

Do not create a separate PHP website with the same hostname. The Python project should own the hostname so Nginx sends requests to the correct application.

3. Point the DNS record at the VPS
If the domain uses Cloudflare nameservers, open the domain in Cloudflare and choose DNS → Records → Add record. For our subdomain we used:

• Type: A
  
• Name: flask
  
• IPv4 address: the lab VPS public IPv4 address
  
• Proxy status: DNS only for this direct-origin certificate test
  
• TTL: Auto
  

Save the record. Check for conflicting records for the same hostname. An AAAA record must point to a working IPv6 origin; do not leave an incorrect IPv6 record in place.

DNS only makes the hostname resolve directly to the VPS. This guide tests Nginx and its certificate at the origin; Cloudflare proxy configuration is a separate step. Allow DNS propagation before requesting the certificate.

4. Enable external network mapping
Return to the project's Mapping section. Turn on External network mapping and confirm the panel's prompt. The panel should detect the running application port. In our lab it detected 3200 and showed Proxy routing is enabled: /.


  flask-mapping-20261014.jpg (Size: 227.67 KB / Downloads: 4)
The Python project's mapping routes website traffic through Nginx to the local application port.

The Firewall Status: Not configured entry for 3200 does not mean you must expose that port. The browser reaches Nginx on 80/443, and Nginx reaches Gunicorn on 127.0.0.1:3200.

Open http://your-hostname/ and check that it displays your Flask response. Our public HTTP check returned HTTP 200. If you see another website, check domain ownership and DNS. If you see 502, check the running process, its bind address and the mapping port.

5. Apply a Let's Encrypt certificate
In the project's management window, open SSL → Let's Encrypt. Choose File Verification, select the exact hostname and click Apply. File verification requires the certificate authority to reach the hostname on port 80.


  flask-ssl-request-20261014.jpg (Size: 161.76 KB / Downloads: 4)
Select only the hostname that resolves to this project before applying for its certificate.

Some panel versions display Not connected to the Domain Management Center and a Connect action. Review that integration before connecting your domain, then return to the certificate request. Wait for issuance to finish; a pending request is not an installed certificate.

In this lab, the SSL section changed to Current Certs — Deployed, listed flask.adminslab.com and showed an expiry date of 12 January 2027. We also validated the live certificate independently. Do not copy or share the private-key field from the certificate screen.

6. Verify HTTPS from outside the VPS
Open https://your-hostname/ in a browser. The page must display the expected application without a certificate warning. From a terminal, you can also test:

Code:Copy

curl -i https://your-hostname/

Do not use curl -k for this check: it skips certificate validation and can hide a broken certificate.


  flask-https-result-20261014.jpg (Size: 27.6 KB / Downloads: 4)
The public HTTPS hostname serves the expected Flask lab response.

Our result: https://flask.adminslab.com/ returned HTTP 200 with AdminsForum Flask lab, and certificate validation passed. This confirms DNS, Nginx mapping, the running application and HTTPS worked together at the time of testing.

Troubleshooting

• DNS points to the wrong server: correct the A record and any conflicting AAAA record, then allow caches to expire.
  
• HTTP works but certificate verification fails: check port 80, redirects, proxy rules and whether the selected hostname is the one attached to this project. Read the issuance error rather than repeatedly submitting requests.
  
• HTTPS shows another site's certificate: confirm this hostname has its own deployed certificate and is served by the expected Nginx project.
  
• 502 Bad Gateway: verify localhost responds, then compare the Gunicorn port with the mapping port and inspect Project logs.
  
• App stops after reboot: this guide does not verify Python reboot recovery. Test and document autostart separately before treating the deployment as production-ready.
  

Completion checklist

• Domain is listed under the correct Python project.
  
• DNS resolves to the intended VPS.
  
• Local Gunicorn and public HTTP both return the expected content.
  
• Mapping uses the application's local port.
  
• SSL is deployed for the exact hostname.
  
• Public HTTPS passes normal certificate validation and returns the expected app.
  

Related: Create a Python Virtual Environment · Run Flask with Gunicorn

Tested and illustrated by AdminsForum. Screenshots show our own lab; use your own domain and application values.]]> https://adminsforum.com/Thread-guide-run-a-flask-app-with-gunicorn-in-aapanel Wed, 14 Oct 2026 14:23:45 +0800 DEV]]> https://adminsforum.com/Thread-guide-run-a-flask-app-with-gunicorn-in-aapanel This guide creates a small Flask application and runs it under aaPanel using Gunicorn and a separate Python virtual environment. The test stops at a verified localhost response; domain mapping and HTTPS are separate steps.

Tested lab: Ubuntu 22.04.5 LTS, aaPanel Free 8.0.7, Python 3.10.12 in af_python_lab, Flask 3.1.3 and Gunicorn 26.2.0. Tested on 14 October 2026. For a new production project choose a currently maintained Python release compatible with the application; the version here records the existing lab system interpreter.

1. Prepare the environment
Follow Create a Python virtual environment in aaPanel. Our application interpreter is:

Code:Copy

/www/server/pyporject_evn/af_python_lab/bin/python

Keep application dependencies separate from aaPanel's own pyenv. Verify the interpreter and pip before installing packages.

2. Create the application folder
Create a fresh folder /www/wwwroot/af-flask-lab and put app.py inside it:

Code:Copy

from flask import Flask app = Flask(__name__) @app.get('/') def home():     return 'AdminsForum Flask lab'

This defines a Flask application object named app in a module named app. There are no credentials, database operations or file uploads in this demonstration.

Use www ownership for this new app folder so the selected run user can read it. The app environment also needs suitable ownership for package installation by the intended user. Apply permission changes only to the newly created application environment and folder, not aaPanel's own Python environment.

3. Install Flask and Gunicorn
As www, use the application's exact interpreter:

Code:Copy

/www/server/pyporject_evn/af_python_lab/bin/python -m pip install --index-url https://pypi.org/simple flask gunicorn /www/server/pyporject_evn/af_python_lab/bin/python -m pip check

We installed from official PyPI and the dependency check returned No broken requirements found. For repeatable real deployments, preserve a reviewed dependency specification instead of always installing whatever version is newest.

Gunicorn is the WSGI server for this example. Do not publish a production Flask site using its development server or enable debug mode on a public deployment.

4. Add the Python project
Open Website → Python Project → Add Project. Set:

• Project Name: af_flask_lab
  
• Python Environment: af_python_lab
  
• Startup Way: Command Startup
  
• Project Path: /www/wwwroot/af-flask-lab
  
• Startup Command: gunicorn --workers 1 --bind 127.0.0.1:3200 app:app
  
• Startup User: www
  
• Environment Variables: None for this non-secret sample
  

The folder field can update the project name automatically in this version; check the final identifier before confirming. We left the dependency-path field empty because the packages were already installed in the selected environment.


  flask-project-create-20261014.jpg (Size: 164.44 KB / Downloads: 4)
Create the Flask project with the isolated interpreter and localhost Gunicorn command.

The app:app argument means load the app object from app.py. The port must be available. One worker is enough for this tiny lab check, not a universal production sizing recommendation.

5. Wait for project initialization
Click Confirm and let initialization finish. Our panel performed additional environment setup before launching the process. A creation dialog completing does not guarantee that the app is already ready for requests.

Click the project name and inspect Project information. Confirm the interpreter, source folder, run user and startup command.


  flask-project-final-20261014.jpg (Size: 144.9 KB / Downloads: 4)
Final project settings retain af_python_lab, the www user and port 3200.

6. Read the startup log
Open Project logs. Our log showed Gunicorn starting, listening at http://127.0.0.1:3200 and booting its worker.


  flask-project-logs-20261014.jpg (Size: 155.79 KB / Downloads: 4)
Actual Gunicorn startup output for the sample project.

If the log reports module not found, check the selected environment and working directory. If it reports address already in use, identify the existing listener before trying another launch. Read the complete error before reinstalling packages.

7. Verify the local response
Over SSH on the VPS:

Code:Copy

curl -i http://127.0.0.1:3200/ ss -ltnp | grep ':3200' ps -eo user,pid,args | grep '[g]unicorn.*3200'

Our response was HTTP 200 with AdminsForum Flask lab. The Gunicorn master and worker ran as www using the selected environment. pip check passed after the panel setup, and the existing Node.js HTTPS website remained healthy.

8. Understand the boundary of this test
The app is listening only on localhost. It is not yet a public HTTPS website. Next, add the intended domain, configure web-server mapping to this port and deploy a certificate. Do not open port 3200 publicly just to bypass the mapping.

Startup-after-reboot is also a separate recovery test. The Startup checkbox for this Python sample remained off during the current test. A successful current response does not prove automatic reboot recovery.

Reference: Flask's Gunicorn deployment documentation.]]> This guide creates a small Flask application and runs it under aaPanel using Gunicorn and a separate Python virtual environment. The test stops at a verified localhost response; domain mapping and HTTPS are separate steps.

Tested lab: Ubuntu 22.04.5 LTS, aaPanel Free 8.0.7, Python 3.10.12 in af_python_lab, Flask 3.1.3 and Gunicorn 26.2.0. Tested on 14 October 2026. For a new production project choose a currently maintained Python release compatible with the application; the version here records the existing lab system interpreter.

1. Prepare the environment
Follow Create a Python virtual environment in aaPanel. Our application interpreter is:

Code:Copy

/www/server/pyporject_evn/af_python_lab/bin/python

Keep application dependencies separate from aaPanel's own pyenv. Verify the interpreter and pip before installing packages.

2. Create the application folder
Create a fresh folder /www/wwwroot/af-flask-lab and put app.py inside it:

Code:Copy

from flask import Flask app = Flask(__name__) @app.get('/') def home():     return 'AdminsForum Flask lab'

This defines a Flask application object named app in a module named app. There are no credentials, database operations or file uploads in this demonstration.

Use www ownership for this new app folder so the selected run user can read it. The app environment also needs suitable ownership for package installation by the intended user. Apply permission changes only to the newly created application environment and folder, not aaPanel's own Python environment.

3. Install Flask and Gunicorn
As www, use the application's exact interpreter:

Code:Copy

/www/server/pyporject_evn/af_python_lab/bin/python -m pip install --index-url https://pypi.org/simple flask gunicorn /www/server/pyporject_evn/af_python_lab/bin/python -m pip check

We installed from official PyPI and the dependency check returned No broken requirements found. For repeatable real deployments, preserve a reviewed dependency specification instead of always installing whatever version is newest.

Gunicorn is the WSGI server for this example. Do not publish a production Flask site using its development server or enable debug mode on a public deployment.

4. Add the Python project
Open Website → Python Project → Add Project. Set:

• Project Name: af_flask_lab
  
• Python Environment: af_python_lab
  
• Startup Way: Command Startup
  
• Project Path: /www/wwwroot/af-flask-lab
  
• Startup Command: gunicorn --workers 1 --bind 127.0.0.1:3200 app:app
  
• Startup User: www
  
• Environment Variables: None for this non-secret sample
  

The folder field can update the project name automatically in this version; check the final identifier before confirming. We left the dependency-path field empty because the packages were already installed in the selected environment.


  flask-project-create-20261014.jpg (Size: 164.44 KB / Downloads: 4)
Create the Flask project with the isolated interpreter and localhost Gunicorn command.

The app:app argument means load the app object from app.py. The port must be available. One worker is enough for this tiny lab check, not a universal production sizing recommendation.

5. Wait for project initialization
Click Confirm and let initialization finish. Our panel performed additional environment setup before launching the process. A creation dialog completing does not guarantee that the app is already ready for requests.

Click the project name and inspect Project information. Confirm the interpreter, source folder, run user and startup command.


  flask-project-final-20261014.jpg (Size: 144.9 KB / Downloads: 4)
Final project settings retain af_python_lab, the www user and port 3200.

6. Read the startup log
Open Project logs. Our log showed Gunicorn starting, listening at http://127.0.0.1:3200 and booting its worker.


  flask-project-logs-20261014.jpg (Size: 155.79 KB / Downloads: 4)
Actual Gunicorn startup output for the sample project.

If the log reports module not found, check the selected environment and working directory. If it reports address already in use, identify the existing listener before trying another launch. Read the complete error before reinstalling packages.

7. Verify the local response
Over SSH on the VPS:

Code:Copy

curl -i http://127.0.0.1:3200/ ss -ltnp | grep ':3200' ps -eo user,pid,args | grep '[g]unicorn.*3200'

Our response was HTTP 200 with AdminsForum Flask lab. The Gunicorn master and worker ran as www using the selected environment. pip check passed after the panel setup, and the existing Node.js HTTPS website remained healthy.

8. Understand the boundary of this test
The app is listening only on localhost. It is not yet a public HTTPS website. Next, add the intended domain, configure web-server mapping to this port and deploy a certificate. Do not open port 3200 publicly just to bypass the mapping.

Startup-after-reboot is also a separate recovery test. The Startup checkbox for this Python sample remained off during the current test. A successful current response does not prove automatic reboot recovery.

Reference: Flask's Gunicorn deployment documentation.]]>