AdminsForum - aaPanel

aaPanel Installation Requirements: VPS, Domain & Setup Checklist

Fri, 09 Oct 2026 18:18:06 +0800

What do you need before installing aaPanel?
You need a clean supported Linux server, its IP address, SSH access and administrator privileges. A domain is optional for the initial installation, but you will need one you control for the domain-based website and trusted HTTPS tutorials. Prepare recovery access and backups before changing the server.

Review status: Official requirements checked on 9 October 2026. This is a preparation checklist. Our fresh-VPS walkthrough, exact tested versions and original screenshots will be added after testing.

1. A VPS or other suitable Linux server
aaPanel runs on the server; buying a domain alone does not provide a place to install it. A VPS is convenient for this tutorial series, but a suitable dedicated server can also be used. An ordinary shared-hosting account without server administration access is not equivalent.

Before choosing an image, check the current official aaPanel installation requirements for the OS release and architecture you intend to use. At this review date, Quick Start lists an installation minimum of 1 CPU core, 512 MB RAM and 1 GB storage. These figures are an installation floor, not a guarantee of capacity for a web server, database and live application.

Leave room for your application, PHP workers, database, logs, updates and backups. Record the actual CPU, RAM, storage and OS version. Do not install aaPanel over another hosting panel or an existing production stack without a supported migration plan.

2. Server IP, SSH and administrator access
Have the correct server IP and the initial username supplied by the provider. Check that SSH works and that you have root access or a sudo-capable account with the privileges required by the installer. Use an SSH client on your computer, such as its existing OpenSSH client.

Keep credentials in a password manager. Never publish passwords, private SSH keys, API tokens or the panel's private entrance URL. Keep a working session open while adjusting access rules.

3. Recovery console, updates and a baseline backup
Open and test the provider's recovery console before changing SSH or firewalls. Confirm how rescue mode and snapshot recovery work. Update the clean OS using its supported package manager, verify server time and plan any required reboot.

Take a baseline snapshot if available. If the server already contains data, make an independent backup and plan recovery or migration before installing anything. A snapshot in the same provider account is useful for rollback but is not an independent off-site backup.

Follow 15 Things to Do After Buying a New VPS for the detailed preparation sequence.

4. A domain and DNS access for the website tutorials
Do I need a domain to install aaPanel?
No. Initial installation can start with the server IP and SSH. Save the actual management address produced by your own installation; do not assume a port or entrance path from another tutorial.

When do I need a domain?
Use a domain you control when connecting a named website and setting up the hostname-based HTTPS examples. A subdomain of an existing domain is enough for the tutorial lab. For example:

Code:

lab.example.com        test website
panel-lab.example.com  panel management hostname

These are placeholders. You need access to the authoritative DNS provider, which may be different from the domain registrar. Preserve existing website, mail and verification records. Use a separate test hostname so the exercise does not move a live site's traffic.

Do I have to buy a second domain?
No. You can use suitable subdomains of one you already control, or a spare domain. Check which DNS records the chosen certificate validation method requires.

5. Access to both firewall layers
Be able to manage the provider/cloud firewall and the server firewall. Preserve your actual SSH port. After installation, restrict the actual panel management port to your management IP or VPN where practical. Public website ports and management access serve different purposes; do not open every port in an example list.

If using IPv6, verify the corresponding routing and access rules before publishing an AAAA record. Test a fresh administrative connection after changes while the recovery console remains available.

6. Know what website you plan to run
Decide whether the first test is static HTML or a PHP application. A static test does not require a database. For an application, check its supported PHP/database versions and required extensions before selecting the stack. Install only the services you need; mail, FTP and optional plugins do not have to be part of the first exercise.

Ready-to-install checklist

A clean server with an OS/architecture supported by the current aaPanel release.
CPU, RAM and disk capacity planned for the workload, not just the installer.
Correct IP, working SSH and the required administrator privileges.
Tested recovery-console access and a baseline snapshot or backup.
OS updates and server time checked.
Access to provider and server firewall controls.
A private place to store credentials and installation details.
For the website/HTTPS stages: a test hostname and authoritative DNS access.
A record of the OS and, later, aaPanel/web-server/PHP versions actually used.

Next: install aaPanel and create a website

Official source: aaPanel Quick Start. Recheck its current requirements before installing; supported releases and installer instructions can change.

Need help checking your setup? Share your OS version, CPU/RAM, intended website and whether you have DNS access. Leave credentials and private connection details out of your post.

aaPanel: Create Your First Website, Connect a Domain, and Enable SSL

Thu, 08 Oct 2026 10:11:40 +0800

How do you put your first website online with aaPanel?
Create the site with the correct domain and document root, confirm DNS points to the intended server, and verify a simple HTTP page. Then issue a certificate for the configured names, test HTTPS, and enable redirects only after it works. Put a small website online, prove that the domain reaches the correct server, then enable HTTPS. Start with a test subdomain if your main domain already serves a live business.

New to the panel? Read our aaPanel introduction and FAQ. This walkthrough assumes aaPanel is already installed and reachable. Interface labels can vary by release. Documentation reviewed 9 October 2026. Fresh-VPS testing and original screenshots are pending; the existing images are vendor documentation examples, not evidence of a tested server. Record the exact aaPanel, OS, web-server and PHP versions when following this walkthrough.

1. Prepare before changing DNS
You need a domain you control, its DNS dashboard, your VPS public IP, and a working web server in aaPanel. For PHP applications, install a supported PHP version compatible with the application. A static HTML test does not need a database.

If replacing an existing site, record its current DNS values and back up files and databases first. Keep the old host working during the change. Changing DNS can send some visitors to the old host and some to the new host while caches expire.

2. Point the domain to the VPS
Edit records at the provider hosting your authoritative DNS zone; this may differ from the registrar where you bought the domain.

Code:

Type    Name    Value
A       @       YOUR_VPS_PUBLIC_IPV4
CNAME   www     example.com

Replace example.com and the IP placeholder with your own values. Some providers require the full domain instead of @. Do not create a CNAME where other records already exist for that same hostname. Leave mail records alone.

Check both names from your computer, if dig is installed:

Code:

dig +short A example.com
dig +short A www.example.com
dig +short AAAA example.com
dig +short AAAA www.example.com

An AAAA record advertises IPv6. Keep it only when that address actually serves this website. An old IPv6 record can cause failures even when the A record is correct. With a CDN proxy, public answers may show the CDN rather than the origin; check the configured origin separately.

For more background: DNS Records Explained.

3. Create the site in aaPanel
Open Website → PHP Project → Add site → Create site. Enter your domain and, if needed, www on separate lines. Check the site-specific Website Path, choose the appropriate PHP version, and create FTP/database accounts only if needed. Confirm the form. For this staged test, leave Apply for SSL off until HTTP works.

Official aaPanel documentation example; your version may look different. The PHP selection shown is illustrative, not a requirement for your application.

4. Prove that the right files are being served
Open the site's directory through aaPanel Files. In a new empty test site, create index.html containing:

Code:




My first website
Website setup works
This is my new VPS website.

Do not overwrite an existing application's index file. Visit http://example.com and http://www.example.com and confirm the exact test text appears. If you see another page, fix DNS or the domain binding before requesting a certificate.

Optional read-only checks from your computer:

Code:

curl -I http://example.com
curl -I http://www.example.com

A response alone does not prove the correct site was served; also check the page content. Upload application files only to the intended site directory, following that application's deployment instructions. Keep backups, private keys and database exports outside the publicly served directory.

5. Issue the website certificate
Open the site's SSL → Let's Encrypt settings. Select the hostnames you actually configured, choose File verification and Apply. HTTP-01 needs public access on port 80, including through the provider firewall. HTTPS traffic needs port 443. Keep administration ports restricted; do not disable the whole firewall.

Official aaPanel SSL example. Despite wording visible in this example, HTTP file verification cannot issue wildcard certificates.

A wildcard requires DNS verification. Manual TXT verification needs ongoing renewal work; it is not automatically renewed by aaPanel's documented manual method. Automated DNS verification should use narrowly scoped credentials where supported. Never post those credentials in a support thread.

6. Test HTTPS before redirecting
Visit https://example.com and the www address. Verify the certificate covers both names and the correct content loads. Do not bypass a browser certificate warning to declare success.

Code:

curl -I https://example.com
curl -I https://www.example.com

These checks use normal certificate validation; do not add -k. Only after HTTPS works should you enable the site's Force HTTPS option, if available. Test again for redirect loops and insecure image/script requests. Delay HSTS until you understand its persistence and all affected hostnames reliably support HTTPS.

7. Troubleshooting without guesswork

Wrong site: Compare DNS answers, domain bindings and the selected document root. Opening the bare IP can show a default site instead of your domain's site.
Timeout: Check whether the web service is running and whether the provider and server firewalls allow the needed web ports. Keep your current administrative session open when adjusting rules.
403 or 404: Confirm the index file and public directory. Use the site's error log to diagnose permissions; do not use chmod 777 as a shortcut.
Certificate validation fails: Read the exact error. Check A/AAAA, port 80 reachability, proxy behavior and the challenge path. Fix the cause before retrying repeatedly, because issuance has rate limits.
Redirect loop: Check application URL settings and CDN/origin HTTPS configuration. Avoid competing redirect rules at several layers.
PHP returns 502: Check the site's selected PHP service and logs. See our aaPanel PHP-switching 502 guide.

8. Make the setup maintainable
Confirm the renewal job is enabled and monitor expiry rather than assuming the first successful issuance guarantees renewal. Schedule backups, keep an off-server copy and test restoration into a separate destination. Record the domain, document root, application version and recovery steps without putting passwords in that note.

Done means: Both intended hostnames serve the correct site; HTTPS validates; redirects behave as intended; renewal is monitored; recovery has been tested.

References and screenshot credits: aaPanel website and SSL documentation; aaPanel deployment guide; Let's Encrypt validation methods. Screenshots are vendor documentation examples, not captures of your server.

Common questions
Do I need a database for the first HTML test?
No. A static index.html page checks domain mapping and file serving without involving PHP or a database. Add those only when your application needs them.

Can HTTP file verification issue a wildcard certificate?
No. A wildcard needs DNS-01 validation. Follow the current certificate-provider and aaPanel instructions for the chosen method.

Why does the site work for me but fail for someone else?
Compare A and AAAA records, DNS caching and CDN origin settings. A stale IPv6 record can point some visitors to another server.

Related setup and troubleshooting

aaPanel Complete Setup Guide for a New VPS

Thu, 08 Oct 2026 01:59:50 +0800

How do you set up aaPanel on a new VPS?
Prepare a clean supported Linux server, install aaPanel from its official source, secure management access, install only the required web stack, and create your website. Verify DNS, HTTPS, service access and a backup restore before moving live traffic.

Review status: Documentation reviewed on 9 October 2026. A fresh-VPS installation run and original screenshots are pending. This is a preparation guide, not a claim that a specific aaPanel/OS release has been tested. Record your OS, aaPanel, web-server and PHP versions when following it.

Scope: A fresh VPS, one small PHP/static website and DNS you control. aaPanel versions, supported operating systems, installer URLs and menu labels change. Check the linked official documentation for your release before installation. This guide does not install mail, FTP or every available plugin by default.

Before starting: Keep the provider console available, verify your SSH access and take a baseline snapshot. Do not install over an existing hosting panel or production web/database stack without a supported migration plan. Never post installer output containing panel credentials or the private entrance URL.

1. Prepare a supported, clean server
Use the current aaPanel Quick Start to confirm supported OS/architecture and resource requirements. Treat the listed minimum as an installation floor, not sizing advice for your workload. Budget RAM and disk for PHP workers, the database, logs, upgrades and backups.

Read-only checks on Linux:

Code:

cat /etc/os-release
uname -m
free -h
df -h
sudo ss -lntup

Patch the OS using its supported package manager and reboot if required before installing the panel. Confirm the clock is synchronized. Record which ports already have listeners. Start with the basics in 15 Things to Do After Buying a New VPS.

2. Install from the official source
Open aaPanel Quick Start and choose the intended edition and supported installation method. Read the installer prompts and any feature/licensing terms before accepting them. Use only the official installer source; do not reuse an old command copied from a blog.

Safer download handling: Download over HTTPS with certificate verification enabled, inspect the saved script and use any vendor-provided integrity/signature checks. Avoid curl -k, wget --no-check-certificate and unreviewed curl-to-shell pipelines. If TLS verification fails, check time, CA certificates and the destination rather than disabling validation. Execute a reviewed installer only on the intended server with the privileges it requires.

Save the resulting panel URL, actual port, entrance path and initial credentials in a password manager. Treat the output as sensitive. Do not assume every installation uses port 8888 or 7800.

3. Establish panel access without broad exposure
Allow the actual panel port through the provider and guest firewalls only from your management IP/VPN where practical. Preserve SSH access. Do not open a vendor example's whole port list if you are not deploying all those services.

Use the full installation-generated URL, including the entrance path. A refused connection, timeout and wrong-path 404 have different causes. Read the troubleshooting section below before changing security settings.

A first installation may use a self-signed panel certificate. Do not enter credentials through an unexplained certificate warning or switch the panel to plain HTTP. Establish trust through a verified certificate procedure or deploy a valid certificate using the vendor-supported process. Independently verify server identity and certificate details through the trusted console/provider path. Keep panel access restricted during setup.

4. Secure panel settings and trusted HTTPS
After trusted access is established, replace initial credentials with a unique password and enable supported two-factor authentication. Keep recovery information privately. Disable panel API access unless needed and scope any API credentials carefully. Configure a sensible session timeout and available security alerts.

Use a dedicated hostname such as panel.example.com with a correct DNS-only A record; publish AAAA only if management access works over IPv6. aaPanel documents Panel SSL under Settings and certificate management under Domains. Deploy a certificate matching the panel hostname, keep the chain/key private and verify renewal.

Panel SSL and website SSL are separate deployments. A certificate on your website does not automatically secure the panel. Binding a panel domain can restrict access to that hostname and block the IP path; do not enable that restriction until DNS, TLS and recovery are proven. Check the current domain access guide for your version. Avoid introducing a reverse proxy/CDN until direct access is stable; ports and real-client-IP handling matter.

5. Install only the required web stack
For a typical PHP website, choose a supported LNMP stack (Nginx, database and PHP) or LAMP if your application specifically needs Apache behavior. Select supported runtime/database versions compatible with the application. Install only necessary PHP extensions and plugins. Do not blindly choose an old PHP release to match an outdated tutorial.

Wait for installation jobs to finish and review failures in the panel. Confirm the web server, PHP-FPM and database are running. Avoid installing a second OS-packaged web/database service over the panel-managed one; conflicting listeners and paths make troubleshooting harder.

6. Create the website and application database
In Website, add the intended domain(s), choose the root directory and runtime. If needed, create a database and a dedicated application user. Save its credentials privately and give that user only the required database access; do not configure the application to use the database administrator account.

Upload trusted application files through a supported secure method. Set the running/document root to the application's public directory where required. Keep environment files, database dumps, archives and private keys outside public access. Use the application's recommended ownership/permissions, never recursive chmod 777.

Choose the supported rewrite template for your framework/CMS. Nginx does not read Apache .htaccess rules. Verify a simple static page first, then an application route and database connectivity. If you create a temporary PHP diagnostic page, restrict it and remove it after testing because it reveals configuration details.

7. Point DNS and deploy website HTTPS
Set the site's A record to the correct public IPv4 address and add AAAA only after IPv6 testing. Preserve existing mail and verification records. Read DNS Records Explained if unsure.

Verify resolution from your workstation:

Code:

dig +short A example.com
dig +short AAAA example.com

Use Website SSL or the Domains certificate manager as supported by your version. Choose a validation method you can complete. HTTP validation needs public access to the challenge path; DNS validation needs the exact TXT record or appropriately scoped DNS API access. Wildcards require DNS validation. Check CAA if issuance is denied.

After issuance, test every hostname in the certificate, the chain and automatic renewal. Enable Force HTTPS only after HTTPS works. Check for mixed content and redirect loops, particularly if a CDN is involved. Do not repeatedly retry issuance without reading the error; CA rate limits can slow recovery.

8. Expose only the intended services
A basic website generally needs public TCP 80/443. Keep management restricted and database/cache ports private. If you do not need FTP or mail, do not install them or open their ports. Review provider and panel/guest firewall rules together, including IPv6. Docker-published ports require separate review if you later add containers.

Check listeners:

Code:

sudo ss -lntup

Test a new SSH/panel session and an external website request after changes. Do not disable the entire firewall to solve a single missing rule.

9. Configure backups, jobs and alerts
Schedule both website-file and application-consistent database backups. Include required configuration, and verify the scope of aaPanel's panel/Backup Restore features rather than assuming every plugin and dependency is included. Local backups consume disk and disappear with the server; send an encrypted copy off-site with retention and limited credentials.

Restore to an isolated temporary server before relying on the backup. Check files, database contents, runtime/extensions and application behavior. Inspect overwrite warnings carefully; never test a restore by overwriting the only live copy.

Add only required application cron jobs using the intended runtime/user. Monitor disk/inodes, failed jobs, uptime, certificate expiry and backup age. Test notification delivery. Keep panel, plugins, runtime and application updates on a documented maintenance schedule.

10. Final acceptance checks

Fresh SSH and trusted panel login work through the intended management path.
The site works over HTTPS, including application routes, uploads and database operations.
Only intended ports are publicly reachable over IPv4/IPv6.
Certificate renewal and scheduled jobs are configured and monitored.
An off-site backup has been restored and checked.
A planned reboot preserves the expected services, access rules and schedules.

Troubleshooting

Panel timeout: Check the actual port, provider firewall, guest rules and listener through the console. Confirm your source IP still matches any allowlist.
Panel 404: Confirm the full entrance path and any bound-domain requirement. Do not share that path publicly.
Website shows a default page: Check DNS/proxy behavior, domain mapping and the active site's document root.
Static page works but PHP returns 502: Check the site's selected PHP version, FPM status and Nginx upstream/error log. See the Nginx 502 troubleshooting guide.
403 or permission error: Inspect the exact log, index/document-root settings, ownership and security policy. Avoid blanket permission changes.
Database connection fails: Check the application host/socket, database name/user and permissions. Keep the database private while fixing it.
Certificate fails: Read the validation log and verify DNS, challenge reachability and CAA before another attempt.

Official documentation

For help, include aaPanel version, OS, chosen stack, the step that failed and a redacted error. Never include panel passwords, database credentials, API tokens, private keys or full installer login output.

Common questions
Can I install aaPanel alongside another hosting panel?
Use a clean supported server. Existing panels and web/database stacks can conflict; use a separate server or a supported migration plan.

Does website SSL also secure the aaPanel login?
No. Website certificates and the panel management certificate are separate. Verify the panel hostname and its certificate independently.

Which panel port should I open?
Use the actual port from your own installation output. Restrict it to your management IP or VPN where practical; do not assume a tutorial's port is correct.

Related aaPanel guides

aaPanel file and log locations: cheat sheet

Wed, 07 Oct 2026 10:03:05 +0800

Where are aaPanel website files and logs?
On a standard installation, site files commonly live under /www/wwwroot/ and site logs under /www/wwwlogs/. Panel-managed software and configuration are commonly under /www/server/. Always confirm the selected site's document root and active service configuration; these examples are not universal paths.

Scope and review: Documentation reviewed 9 October 2026. These are common Linux aaPanel layouts. Custom roots, versions and web servers can differ. Exact paths and screenshots will be checked on the tutorial VPS; PHP 8.3 below is an example, not a version recommendation.

1. Website directory and logs

Code:

/www/wwwroot/example.com/
/www/wwwlogs/example.com.log
/www/wwwlogs/example.com.error.log

Replace example.com with the actual site. Open its aaPanel document-root and log controls to confirm the location. For frameworks, the public/running directory may be a subdirectory of the project. A blank or absent log is not evidence that the application is healthy.

2. Common web-server configuration locations

Code:

/www/server/nginx/conf/nginx.conf
/www/server/panel/vhost/nginx/
/www/server/panel/vhost/apache/
/www/server/panel/vhost/rewrite/

These are location examples, not commands to execute. Nginx, Apache and OpenLiteSpeed use different configurations. Prefer the panel's supported editor, save a backup and validate the correct service configuration before applying a change. Panel-generated files may be regenerated later.

3. PHP-FPM examples

Code:

/www/server/php/83/etc/php.ini
/www/server/php/83/etc/php-fpm.conf
/tmp/php-cgi-83.sock
/etc/init.d/php-fpm-83

Replace 83 with the installed version selected for the site. Confirm the actual listen value and upstream path: the command-line PHP version can differ from the website's PHP version. The socket is a service endpoint, not a file you should create manually.

4. Common data, panel and backup directories

Code:

/www/server/data/
/www/server/panel/
/www/backup/

Do not copy live database files as a substitute for a consistent database backup. Confirm the active data/backup paths in your configuration. A backup on the same disk does not protect against losing the server. Keep exports, archives and private configuration outside the site's public directory.

5. Read the relevant error, then verify
A read-only example for a confirmed site error-log path:

Code:

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

Reproduce the failing request once and correlate its time with the new log entry. Check both the web-server error and the relevant PHP/application log. Logs can contain credentials or personal data: redact them before sharing.

If a path is missing: Check whether the service is installed, which stack/version is active, and whether the site uses a custom directory or disabled logging. Do not create a guessed socket, recursively change permissions or delete files to make the example match.

Official references: Site directory and log controls; Service commands and common configuration paths.

Related: Diagnose a PHP-switching 502 · Website and SSL setup.

aaPanel: first steps after install to secure your panel

Wed, 07 Oct 2026 10:03:05 +0800

How do you secure aaPanel after installation?
Restrict management access, use trusted HTTPS and strong authentication, keep the panel and software updated, and prove an off-site backup restore. Test a new login after each access change while keeping SSH and the provider console available.

Scope and review: Documentation reviewed 9 October 2026. Menu names depend on the aaPanel release. Fresh-VPS testing and screenshots are pending; no exact release is claimed as tested. Record your OS and panel version before following this checklist.

1. Confirm recovery before changing access
Check that the provider console and a fresh SSH login work. Save current settings and the actual panel port privately. Keep the installation-generated entrance path confidential. It reduces casual discovery but is not a replacement for authentication or a firewall.

Changing the panel port is optional. If you do change it, permit the new port in both firewall layers first, test it, then remove the old rule when appropriate.

2. Use strong authentication
Replace initial credentials with a unique password and enable the supported authenticator/2FA feature. Store recovery information privately and test a fresh session before closing the original. Disable unused API access; protect and limit any credentials you need.

3. Verify trusted panel HTTPS
Panel SSL is separate from website SSL. Use a certificate matching your management hostname and verify its chain and renewal process. A self-signed certificate needs an independently verified trust procedure; an unexplained browser warning is not proof of the correct server. Avoid plain HTTP for panel credentials.

If binding a management domain, prove DNS and HTTPS first. Domain binding can change which URL allows access, so keep a recovery path.

4. Restrict management traffic
Allow the actual management port only from your fixed IP or VPN where practical, using both provider and guest firewall rules. Check how IPv6 is handled. If your IP changes, update the allowlist through the trusted recovery path. Do not disable the whole firewall to fix one rule.

A basic public website needs its web ports; the panel, databases and caches should not be broadly exposed. Open mail or FTP ports only when deliberately deploying those services.

5. Verify SSH-key access before disabling passwords
Create and test a named administrator with keys and sudo first. Validate SSH configuration, inspect effective settings and test a new connection before removing the old access method. Follow the VPS access and firewall checklist for Ubuntu/Debian examples; adapt it to your OS and MFA requirements.

6. Maintain updates and recoverable backups
Use supported panel/plugin/runtime updates and check OS-update compatibility. Schedule website and application-consistent database backups, store a copy outside the VPS, and test restoration into an isolated destination. Monitor backup age, disk space, failed jobs and certificate expiry.

Verify before calling it finished

A fresh trusted panel login and your intended 2FA flow work.
Management access is limited as intended over IPv4 and IPv6.
SSH and the provider recovery console remain available.
Renewal, update and backup jobs are monitored.
An off-site restore has been checked.

Locked out? Check the actual port, current source IP, bound hostname and entrance path through the trusted console. Use the documented bt maintenance menu only after identifying the cause; do not remove protections indiscriminately.

Official references: Panel settings; Management-domain access; Ubuntu OpenSSH guidance.

Related: aaPanel setup checklist · File and log locations.

What is aaPanel? A quick introduction for new users

Wed, 07 Oct 2026 10:03:05 +0800

What is aaPanel?
aaPanel is a browser-based control panel for Linux servers. It helps you manage websites, PHP, databases, certificates, files and backups from one dashboard. Its core is free, while Pro features and some plugins or services may cost extra. You still need to pay for your server and domain.

Review status: Official documentation reviewed 9 October 2026. This introduction is not a hands-on benchmark or a claim that a specific release has been tested. Original VPS walkthroughs and screenshots are pending.

What can it manage?

Website domains, document roots, PHP selection, rewrites and redirects.
Web-server and database software through the supported panel workflow.
Website certificates, file management and scheduled jobs.
Website/database backups and supported remote-storage integrations.

Available features depend on the edition, plugins and installed versions. Check compatibility and licensing before relying on a feature. Installing a panel does not replace Linux administration, updates or a recovery plan.

Before installing
Use a clean supported Linux server and check the current OS/architecture requirements in aaPanel Quick Start. Do not install it over another hosting panel or an existing production stack without a supported migration plan. Size RAM, CPU and disk for your application, database, backups and traffic; an installation minimum is not a production capacity guarantee.

The installer prints a management URL, entrance path and credentials. Store these privately. The trusted server console can display the current panel details with:

Code:

bt default

That output is sensitive: do not post it in the forum or include it in a public screenshot. Running bt opens the panel maintenance menu; read each option before using it.

Common questions
Does aaPanel provide the VPS itself?
No. The panel is software installed on a server you obtain separately.

Are all features free?
No. Check the current edition and individual plugin/service terms. A free core does not mean every add-on is included.

Does every SSL certificate renew automatically?
No. Renewal depends on the validation method, credentials and scheduled jobs. aaPanel documents that manual DNS TXT validation does not provide automatic renewal. Monitor expiry and verify your chosen renewal process.

Can it serve unrelated hosting customers?
Evaluate the intended permissions, isolation, limits and recovery workflow before choosing it for customer hosting. A sub-account alone is not proof of isolation.

Choose your next step

Official references: Quick Start; Website and SSL management. For help, share your OS, aaPanel release, web server and a redacted error, not credentials.

Fix: 502 Bad Gateway after switching a site's PHP version in aaPanel

Tue, 06 Oct 2026 20:15:02 +0800

How do you fix a 502 after changing PHP version in aaPanel?
Check the site's Nginx error log, confirm its selected PHP version, and verify that the matching PHP-FPM service is healthy and listening where Nginx expects it. Restore the last working selection if necessary and application-compatible. A 502 alone does not identify the cause.

Scope and review: Documentation reviewed 9 October 2026. This covers Nginx with panel-managed PHP-FPM after a PHP-version change, not every 502 or an OpenLiteSpeed/Apache deployment. Fresh-VPS reproduction and screenshots are pending. Record aaPanel, OS, Nginx and PHP versions. PHP 8.3 and example.com below are placeholders.

1. Correlate the failure with the site's error log
Confirm the actual log path in aaPanel and reproduce one failing request:

Code:

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

If the log reports:

Code:

connect() to unix:/tmp/php-cgi-83.sock failed (2: No such file or directory)

Nginx cannot find that configured Unix endpoint. The selected service may be stopped, may have failed to start, or may listen somewhere else. Confirm both sides before changing configuration.

Different messages need different checks:

Permission denied: inspect socket ownership/mode and security-policy denials; do not use chmod 777 or disable security globally.
Connection refused: check whether the configured listener is active.
Upstream timed out: investigate slow application/database work and resource pressure; do not blindly increase timeouts.

2. Check the selected PHP service
Prefer the panel's PHP service controls. If this installation uses the documented init script, an example status check is:

Code:

sudo /etc/init.d/php-fpm-83 status
ls -l /tmp/php-cgi-83.sock

A socket file alone is not proof of a healthy service. Compare the site's upstream with PHP-FPM's configured listen endpoint. Do not create the socket yourself or change the application's PHP version without compatibility checks.

3. Inspect startup/configuration errors
A configuration check for this example installation:

Code:

sudo /www/server/php/83/sbin/php-fpm -t

If validation fails, read the reported file and setting. Possible causes include invalid configuration or an incompatible/missing extension. Install only extensions required by the application for the selected PHP version; do not disable arbitrary extensions or security controls as a shortcut. After correcting the cause, start the affected service through the panel. If using the matching init script:

Code:

sudo /etc/init.d/php-fpm-83 start

Changes to a shared PHP service can affect other sites using it.

4. Validate Nginx only if its configuration changed
Use the panel-managed binary on this example installation:

Code:

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

Do not reload if validation fails. If validation passes and the configuration was deliberately changed, use the supported panel reload control. Restoring PHP-FPM alone may resolve the failure without changing Nginx.

5. Verify recovery and keep a rollback path

The selected PHP service stays running and the expected listener is active.
A real PHP/application route loads, not just a static HTML page.
A new request produces no matching upstream error.
Other sites using that PHP version still work.
Required extensions and application/database operations are checked.

If a live site remains down after a version switch, consider restoring its previous working PHP selection through the panel while diagnosing, provided the application still supports it. Back up settings before further changes.

For help: Share the version details, selected PHP version, time of failure and a few redacted error lines. Do not share credentials, tokens or a full configuration dump.

Official references: aaPanel PHP selection and logs; Nginx FastCGI upstreams; PHP-FPM configuration.

Related: aaPanel file and log locations · Setup checklist.