Mail clients need a trusted certificate covering the server hostname they connect to, such as mail.example.com. A certificate covering only example.com and www.example.com is not sufficient for mail.example.com.
Lab result: A certificate for mail.adminslab.com was issued and deployed to the mail services. IMAP on port 993 and SMTP STARTTLS on port 587 both passed hostname and certificate-chain verification. The web site continued returning HTTP 200.
1. Check DNS and the certificate names
Create the mail hostname A record pointing to your VPS and keep it DNS only on Cloudflare. Check whether you already have a valid certificate that explicitly includes mail.example.com. Do not select the website certificate merely because it belongs to the same parent domain.
2. Issue a hostname certificate
Our lab used an HTTP-01 certificate issued through aaPanel's Website feature:
1. Open Website and click Add site.
2. Enter mail.example.com as the domain.
3. Use a separate directory for this hostname. Do not replace an existing website's files.
4. Leave FTP and database creation disabled for a validation-only site.
5. Keep Apply for SSL selected and submit.
6. Wait until the site appears with a valid certificate and a remaining-days value.
Port 80 must be reachable for HTTP-01 validation. If you cannot use HTTP-01, aaPanel also offers DNS verification under Domains → SSL Certificate → Let's Encrypt. Manual DNS validation requires adding the exact challenge TXT record and needs a renewal plan; aaPanel warns that manually resolved certificates do not support automatic renewal.
3. Deploy the certificate to Mail Server
Open Mail Server → Mail Domain and select the SSL status on the domain row. The dialog offers Other certificate and Apply for SSL.
If an existing matching certificate is offered, inspect its certificate-domain list before selecting Deploy. In our lab that automatic selection initially offered only the root/www certificate, so we did not deploy that mismatched certificate.
For a separately issued mail-host certificate, use Other certificate: paste its matching private key into KEY and its full certificate chain into CRT/PEM, then save. Obtain both from the same certificate entry. Never share the private key or put it in a tutorial screenshot. Our lab deployment was performed through the official mail plugin's certificate method; the encrypted-service checks below confirmed the result.
4. Test the mail endpoints
Configure clients with mail.example.com, not the bare IP. Check IMAP TLS on 993 and SMTP STARTTLS on 587. The certificate should be trusted, unexpired and valid for that exact hostname. A working HTTPS website alone does not verify these mail endpoints.
Renewal and troubleshooting
Monitor expiry and confirm that renewed files are redeployed to Postfix and Dovecot. Issuing a renewed website certificate does not by itself prove the mail-service copy was refreshed. Retest both endpoints after renewal.
A name mismatch means the certificate lacks the hostname used by the client. An incomplete chain means intermediate certificates may be missing. A connection timeout requires checking the service, server firewall and provider firewall. Do not disable certificate verification to conceal an error.
Add your email domain to aaPanel Mail Server, then assign the hostname that email clients and receiving servers will use.
Tested lab: Ubuntu 22.04.5, aaPanel Free Edition 8.0.6, Mail Server 7.4.1. We added adminslab.com with the hostname mail.adminslab.com. Replace these examples with your own domain and VPS IP.
1. Prepare the domain and hostname
The mail domain is the part after @ in an address: example.com in [email protected]. The mail hostname is a server name such as mail.example.com. These are different fields. Install and initialize Mail Server first, and sign into the separate aaPanel.com account if the dashboard requests it.
In your DNS provider, create an A record named mail pointing to the VPS public IPv4 address. On Cloudflare, select DNS only for this mail hostname. Wait until a public DNS lookup returns the correct IP before adding the domain. An orange-cloud proxy does not proxy ordinary SMTP or IMAP connections.
2. Open Add Domain
1. Sign into your VPS aaPanel.
2. Select Mail Server in the left menu.
3. Open Mail Domain.
4. Click Add Domain.
5. Select Manual for DNS records when you will manage the records yourself. Automatic mode requires a configured DNS-provider integration; do not assume it is connected.
3. Fill the fields
Domain name: example.com, without https://, a path or an email username.
A record: mail.example.com, whose A record points to this VPS.
Domain quota: total storage allowance for the mail domain. Our lab used 5 GB. This is a quota, not disk space reserved automatically.
Mailboxes: permitted mailbox count. Our lab left the default 50; this is not 50 created users.
Catch All: leave blank initially. Create a real destination mailbox before configuring catch-all forwarding.
Click Confirm once and wait for the adding-domain message to finish.
4. Verify the result
The domain must appear in the Mail Domain table. Check its spelling, quota and mailbox limit. In our lab the new row showed adminslab.com, a 5 GB quota and a limit of 50. No mailbox is created by this operation.
Click DNS Record on the domain row. aaPanel displays the domain-specific MX, SPF, DKIM and DMARC values. Use that screen for the next DNS lesson. DKIM keys are unique; never copy another site's key.
Troubleshooting
A record resolution failed: verify the exact hostname, VPS IP, DNS-only setting and public DNS resolution.
Domain exists: inspect the existing row instead of adding it again.
SSL Not Set: configure a certificate covering the mail hostname; adding the domain alone does not complete TLS.
Next: Configure the required DNS records, create a mailbox and test encrypted connections. This guide ends at successful domain creation.
Screenshot: completed lab domain
The screenshot shows the later completed setup: SSL and WebMail are separate follow-up steps.
Install the official Mail Server app in aaPanel Free Edition before adding your email domain or creating mailboxes. This lesson covers the installation task and service verification; DNS, certificates and delivery are separate lessons.
Test environment: Ubuntu 22.04.5, aaPanel Free Edition 8.0.6, 2 vCPU, 4 GB RAM and a 40 GB disk. The app offered Mail Server 7.4.1 on 11 October 2026.
1. Check the VPS before installation
Use a test server or take a recoverable backup first. Installing a mail server adds services and uses disk and memory; it is not just an extra button in the panel. Confirm that you have administrator access, free disk space and a domain whose DNS you control. Our lab had roughly 29 GB disk space available and 3 GB memory available before installation.
Check whether another mail server already occupies the SMTP/IMAP ports. Do not stop an existing production mail service merely to make a new installer work. Our initial listener check showed no existing SMTP or IMAP service.
Check outbound TCP port 25 with your provider. Our lab received an SMTP greeting from Google's receiving server, so that one outbound connection worked. This does not prove inbound port 25, recipient acceptance or inbox delivery. Providers can restrict port 25 independently of your local firewall.
2. Find the official Mail Server app
1. Sign in to the aaPanel installed on your VPS.
2. Select App Store in the left menu.
3. Enter Mail in the app search box and press Enter.
4. Find Mail Server with developer official and price Free.
5. Check the supported operating systems in that row. Our Ubuntu 22 server is listed.
6. Click Install on the Mail Server row.
The separate Anti-Spam Gateway search result is a different app. Do not install it instead of Mail Server.
3. Start the installation task
The installation window in our lab displayed Mail Server 7.4.1. Read the version, description and dependency warning before proceeding. If the plugin already exists, the installer warns that its files will be replaced.
Installation window: check the official app and version, then select Install Now.
Click Install Now once. aaPanel opens its Messages Box and adds Install[mail_sys-7.4.1] to the task queue. Open its execution log to follow progress. The app downloads software and installs dependencies, so this can take several minutes.
Do not click Install repeatedly. A Waiting install label or a successful task-queue message means the task was queued; neither is a completed installation. Compilation output also does not mean the queue is frozen.
4. Verify the installed services Verified result, 11 October 2026: The installed plugin metadata reports Mail Server 7.4.1. Postfix, Dovecot and Rspamd report active. Redis responds but requires authentication. The lab website still responds successfully over HTTPS. No mailbox or external mail delivery is claimed at this stage.
After the task completes, return to the app list and open the Mail Server management screen. Record the actual service state. Check any initialization or missing-dependency messages rather than assuming all mail services are ready because the plugin appears installed. In our lab the new Mail dashboard requires an aaPanel vendor account before its configuration controls become available. The VPS panel login alone does not satisfy that separate account requirement.
5. Sign in to the separate aaPanel account
Open Mail Server from the left menu after the installation finishes. In our tested version, the management screen required an aaPanel.com account. This is different from the username/password used to enter your VPS panel. It is also different from the mailbox account you will create later.
If you already have an aaPanel.com account, use its email address and password in the vendor sign-in window. If you register a new account, use an email address that already receives messages. Do not use an address on the new mail domain before you have configured that domain and created its mailbox. Complete any verification requested by the vendor. Our lab used an existing working email and the account was bound successfully.
6. Initialize the mail-server environment
On the Mail dashboard, follow the environment Install or restore prompt if it appears. The Restoring the mail server environment dialog checks HostName, Postfix, Dovecot, Redis, Rspamd, SQLite support and SELinux. Read every row before pressing Submit.
Our lab initially failed HostName because it was only websrv. A mail hostname should be a full hostname, such as mail.example.com. Choose the name you will later use for the mail DNS A record. Our lab uses mail.adminslab.com. On our Ubuntu 22.04 lab, we set the static hostname over SSH:
Replace mail.example.com with your own hostname. This command changes the operating-system hostname; it does not create a DNS record or a PTR record. Existing servers may depend on their hostname, so check those dependencies before changing one.
Environment check: all nine rows are Ready before selecting Submit.
Return to the initialization dialog and click Refresh. All nine checks displayed Ready in our lab. Click Submit once and let the initialization log finish. aaPanel writes the mail-service configuration and starts the environment.
7. Confirm the installation outcome
After initialization, open Mail Domain. The Add Domain button should be available. An empty domain list is expected at this stage: you have installed the mail server, but have not added a mail domain yet.
For an additional service check on our Ubuntu lab, we used:
Code:
systemctl is-active postfix dovecot rspamd
All three returned active. These are installation checks. An active service does not prove that Internet email will arrive or reach an inbox. Domain, DNS, TLS and delivery tests follow in separate lessons. What installation does not complete
You still need a mail hostname, the domain's MX record, mailbox users, mail certificates and sender-authentication records. Reverse DNS is configured by the VPS provider. A website working over HTTPS does not prove email works.
Troubleshooting
Still installing: Read the latest execution-log lines. If dependencies are downloading or compiling, let the active task finish.
Download or package error: Record the exact failing URL/package and error. Check connectivity and disk space before retrying.
Port conflict: Identify the service already listening. Preserve an existing mail deployment rather than removing it blindly.
Mail features ask for an aaPanel account: This vendor account is separate from the VPS panel login and the email mailbox. Follow the actual account flow if required.
Next lesson: Add adminslab.com to Mail Server and configure mail.adminslab.com. Do not send verification emails to [email protected] until the mailbox and receiving DNS are ready.
To diagnose a website error in aaPanel Free Edition, reproduce it once, note the time and URL, then match that request in the access and error logs. The status code tells you what the visitor received; the error log can explain what failed.
Tested by AdminsForum: 11 October 2026, Ubuntu 22.04.5, aaPanel Free Edition 8.0.6 and Nginx 1.30.5. We requested a deliberately missing page on adminslab.com, confirmed HTTP 404, and found matching entries in both logs. No website files or service settings were changed for this test.
1. Reproduce the problem and record the time
Open the affected URL once. Write down its path, the approximate time, and the message shown. Use a harmless missing path on your own test site if you want to practise:
The first is the access log; the second is the Nginx website error log. Open them for viewing. Do not clear, delete, or save edits to the logs while diagnosing the incident. File names can differ: confirm your site's access_log and error_log paths in its Nginx configuration if these names are absent.
If you use SSH instead, read recent entries with these commands, replacing the domain with your own site's actual log name:
Read it in order: request time, GET path, protocol, response status, response size, referrer and client software. The 404 after the quoted request is the response code. Here +0000 means UTC; convert your browser's local time before comparing. A browser request may have a different user-agent from this SSH test.
4. Read the matching error entry
Search the same path in the error log:
open() "/www/wwwroot/adminslab.com/af-log-tutorial-missing-page" failed (2: No such file or directory)
This confirms Nginx tried to read a path that did not exist. If it should be a real file, check the upload location and spelling, including letter case. If it should be a WordPress route, inspect the site's rewrite rules instead of creating an empty file to hide the error.
5. Choose the next check from the evidence
404 / file not found: Check the document root, requested path, file name and application routing.
403 / permission denied: Check the exact path's ownership, permissions and access rules. Do not apply chmod 777 as a general fix.
502 / upstream connection failure: Check the selected PHP version, its PHP-FPM service and the configured socket or port. An upstream timeout has a different investigation from a refused connection.
500: Check application and PHP logs too. A web-server access entry alone usually does not identify the application exception.
You may see requests for .env, .git or other paths you never opened. These can be automated scans. Match the URL and time of your actual problem before changing anything. A missing-file scanner entry alone does not establish that your site was compromised.
6. Verify and ask for help
After fixing the identified cause, reload the affected page and check its new status. Keep the original error evidence; it helps confirm what changed. When asking for support, include the panel version, web server, selected PHP version, affected path, timestamp/timezone and a few relevant redacted lines. Remove IP addresses, session tokens, private entrance URLs and query strings containing secrets.
Quick answer
aaPanel offers Multi-WebServer Hosting for choosing a web engine per website. Prepare backups and a clean configuration before enabling it. This article covers the requirements, not a completed multi-server installation.
What it changes
According to aaPanel’s documentation, enabling the feature installs Nginx, Apache and OpenLiteSpeed and manages their port conflicts. It supports individual engines and Nginx proxy combinations. Nginx normally fronts the proxy setups on ports 80/443; the other engines use separate backend ports.
Where the setting is
In our aaPanel Free Edition 8.0.6 lab: Website → Nginx version button → Web server → Multi-WebServer Hosting. The screenshot shows the actual switch turned OFF.
Prepare before enabling
1. Back up website files, databases, certificates and server/site configuration. Keep a copy outside the VPS.
2. Record the current site’s PHP version, extensions, redirects and rewrite rules.
3. Review aaPanel’s warning about manually changed configuration. A custom working Nginx rule is not automatically compatible with another engine. Test the change in a separate lab before migrating an active website.
4. Check for conflicting listeners on the ports listed in the panel. Do not expose backend or management ports publicly just to satisfy the installer.
5. Plan a maintenance window and a tested way back to the current setup.
PHP needs a separate check
Nginx/Apache PHP is managed through the PHP app. OpenLiteSpeed uses lsphp, managed separately; existing PHP extensions may need to be installed there too. Verify the website’s actual runtime after changing engines.
Our verification
On 11 October 2026 we confirmed the setting is available in the Free Edition lab. We did not enable it: the existing WordPress subfolder has custom Nginx rewrite rules. We are keeping that working environment intact until the migration prerequisites are satisfied. No multi-webserver performance or successful migration is claimed here.
Quick answer
A 502 after a PHP change often means Nginx cannot reach the selected PHP-FPM service. Check the website’s PHP version, that version’s service status, and the Nginx error log before changing anything. A 502 can also come from another application upstream.
1. Check the selected PHP version
Open Website → your domain → PHP Version. Confirm the intended version is installed. Save the selection again if the switch did not complete. Back up the site configuration before editing it.
2. Check PHP-FPM
Open App Store → Installed → the matching PHP version → Settings → Service. If stopped, start it. If startup fails, inspect its log first. Restart only the affected service after resolving the reported problem.
3. Read the Nginx error log
Open the website settings and its error log. “No such file or directory” for a Unix socket usually means the configured socket does not exist. “Connection refused” means the upstream is not accepting connections. A timeout needs a different investigation: slow code, resource limits, or the upstream application. Do not fix these by opening database ports or applying 777 permissions.
4. Correct the mismatch
Prefer aaPanel’s PHP Version selector so it generates the appropriate configuration. If custom Nginx rules override PHP handling, back them up and inspect the conflicting fastcgi_pass setting. Use the actual socket of the installed version, not a copied path from another server. Test Nginx configuration before reloading.
Our controlled test
Tested 11 October 2026 on Ubuntu 22.04, aaPanel Free Edition 8.0.6, Nginx 1.30.5 and website PHP 8.5.11. We deliberately pointed one temporary PHP URL to a nonexistent socket. That URL returned HTTP 502 while the homepage and WordPress remained HTTP 200. The screenshot uses our original branded error page.
We restored the backed-up rewrite configuration, passed the Nginx configuration test and reloaded it. The same PHP URL then responded successfully. This demonstrates an upstream mismatch, not every possible cause of a 502.
5. Verify recovery
Reload the affected PHP page, check a normal website page and review the latest error log. If the problem began with an application upgrade, verify its PHP compatibility and required extensions too. Remove temporary diagnostic pages when finished.
Quick answer
Use SFTP over your server's SSH connection to transfer website files securely. On Windows with OpenSSH Client available, open PowerShell, connect with sftp, navigate to the website's document root and upload with put. Verify the exact file URL afterward.
SFTP is different from FTP
SFTP uses encrypted SSH transport. It does not use the FTP service or FTP data-port range. An aaPanel FTP account is not automatically an SSH/SFTP account. Use an authorized SSH account with the required folder access. See the OpenSSH SFTP manual for command options.
Before connecting
Confirm the server hostname/IP and actual SSH port.
Have an existing authorized SSH account and its authentication method.
Verify the server's host-key fingerprint through a trusted source before accepting a first connection. Do not disable host-key checking to silence a warning.
Confirm the website document root in aaPanel Website → site settings → Directory.
Back up existing files before replacing them. Prefer a scoped account for routine transfers rather than administrator/root access.
1. Confirm Windows has the client
Open PowerShell and run:
Code:
Get-Command sftp
If the command is unavailable, install/enable the official Windows OpenSSH Client feature using Microsoft's instructions for your Windows version. This guide assumes the client is already present; installation of the Windows feature was not needed in our lab.
Replace the user, host, port and key path with your own values. The -P option for sftp is uppercase. Never copy another person's private key or post yours in a support thread. If the key has a passphrase, enter it privately when requested.
3. Check local and remote folders
At the sftp prompt, use pwd to check the remote location and lpwd for the local location. Move to the confirmed website folder and your local upload folder:
Code:
cd /confirmed/website/document-root
lcd "C:/path/to/local/files"
ls
The example remote path is a placeholder. Accounts restricted to a chroot can show a different path from the full server path, so use the path available to that account.
4. Upload a new test file
Use a harmless file with a new filename first:
Code:
put adminsforum-sftp-demo.html
ls adminsforum-sftp-demo.html
bye
Check whether a same-named file exists before uploading; put may overwrite it. For a full website, also transfer its referenced assets into the correct folders, and verify ownership/permissions expected by the application.
Original AdminsForum demo uploaded from Windows with SFTP and opened over HTTPS.
Our lab uploaded both a harmless text file and the branded HTML demo, confirmed the remote filenames and checked the HTML page through the browser. Existing homepage files were not replaced.
Common problems
Connection refused or timeout: check the SSH service, port and firewall/provider rules.
Authentication failed: check the SSH username, selected key and account authorization. The panel login and an FTP login are not interchangeable with SSH credentials.
Permission denied while uploading: confirm the account can write to the intended folder. Do not use 777 as a blanket fix.
Host key changed: verify the new fingerprint with the server administrator/provider before changing the trusted entry.
Upload succeeds but URL is 404: check the domain document root, spelling, capitalization and actual uploaded location.
What we tested
On 11 October 2026, Windows OpenSSH SFTP transferred original demo files to our disposable Ubuntu/aaPanel lab using an existing SSH key and a previously verified host-key entry. The lab used its existing administrator SSH account; this test does not claim a restricted production SFTP user was created. Routine production transfers should use appropriately scoped access. No FTP firewall ports or new public services were opened for this test.
Quick answer
If WordPress pages work with ?p=123 but pretty post URLs return 404 on aaPanel with Nginx, check both WordPress Settings → Permalinks and the site's Nginx rewrite configuration. Saving WordPress permalinks does not make Nginx read .htaccess.
Before changing rules
Back up the current rewrite configuration and record the current WordPress permalink setting. Confirm the site's web server is Nginx and whether WordPress is installed at the domain root or inside a folder. This guide is for a single WordPress installation, not Multisite.
1. Choose the WordPress URL format
Log in to WordPress, open Settings → Permalinks, choose Post name if that is the structure you want, and click Save Changes. On our fresh lab site the structure changed from plain query URLs to /%postname%/.
AdminsForum WordPress lab: Post name selected in Permalink Settings.
For an established site, changing public URL structure needs a redirect plan for existing links. This example uses a new disposable lab site.
2. Open the aaPanel rewrite configuration
Open Website → the intended site's settings → URL rewrite. Read and back up the existing rules before editing. Preserve unrelated HTTPS redirects and other application rules. Do not create duplicate location blocks.
3. Use the rule matching the installation folder
Our lab has WordPress in /wordpress/, while the domain root contains other tutorial examples. We added this site-specific block to its rewrite configuration:
This checks for an existing file or directory first, then sends other requests in that folder to WordPress. Query parameters are retained. The site's existing aaPanel PHP handler remains responsible for executing PHP.
If WordPress is installed at the domain root instead, the usual fallback is:
Choose the correct block, not both indiscriminately. The root example assumes the root is actually your WordPress installation. If a matching location already exists, update that block rather than adding a duplicate. Custom proxies, caching, Multisite or other applications need configuration suited to their setup.
4. Save and validate
Save the aaPanel rewrite configuration and confirm there is no configuration error. An operator with SSH can also run the aaPanel Nginx binary's configuration test:
Code:
/www/server/nginx/sbin/nginx -t
Only reload a valid configuration. If validation fails, restore your saved rules and investigate the exact error. Our lab configuration passed before reload.
5. Test an actual post URL
Open a published post using its new URL, not only the homepage. Our lab test was /wordpress/hello-world/. It returned HTTP 200 and the expected post title after the change.
Also check a page, the WordPress homepage, existing static files and any other applications sharing the domain. Our domain homepage and File Manager demo continued returning HTTP 200.
Rollback
Restore the previous rewrite configuration if the new rules cause problems. If you changed WordPress's permalink structure, restore the recorded previous setting as appropriate. Preserve the existing PHP and HTTPS configuration rather than replacing the whole virtual host.
Common problems
Duplicate location error: edit the existing matching location instead of adding another.
Homepage works but posts 404: verify the fallback path and installation folder.
Other applications stop working: a root-level catch-all may be routing their requests to WordPress. Use a correctly scoped block.
PHP source is exposed: stop and repair the site's PHP handler before proceeding; a rewrite rule alone is not PHP configuration.
Redirect loops: review HTTPS/proxy and WordPress home/siteurl settings separately.
Verified on 11 October 2026
We backed up our lab's existing rewrite configuration, added a /wordpress/ fallback, passed the Nginx configuration test, selected Post name through the WordPress dashboard and tested the published post URL. WordPress 7.1.3 ran on PHP 8.5.11 with aaPanel Free Edition 8.0.6. The domain homepage and original static demo remained available.
Quick answer
To install WordPress manually on aaPanel Free Edition, prepare a working PHP website with HTTPS, create a dedicated database/user, place the official WordPress files in the intended website folder, supply the database configuration, and complete installation. Verify both the site and login page.
Requirements
A domain already pointing to the VPS and a working HTTPS website in aaPanel.
A compatible PHP version with the extensions your application requires.
MySQL or MariaDB and a dedicated database user. Our lab uses MariaDB 10.11.
A backup if you are using a folder or database that already contains anything important.
1. Decide where WordPress should live
For a fresh website homepage, place the WordPress package contents in that site's document root. For a separate installation under /wordpress/, keep the package in that subfolder. Do not accidentally create an extra nested wordpress/wordpress folder.
Our dedicated lab uses https://adminslab.com/wordpress/ so the original homepage and other tutorial examples remain available. This is an example URL, not the location you should enter for your own site.
2. Create a dedicated database
Use Databases → MySQL → Add DB in aaPanel, or the equivalent panel-managed database operation. Record the database name, username, password and host privately. Use a user scoped to the application database; do not put the MariaDB root password into WordPress.
3. Download the official package
Get the package from WordPress.org. Extract the ZIP on your computer and upload its contents to the chosen folder using File Manager or a secure transfer method. Confirm files such as index.php, wp-admin and wp-includes are in the intended location.
Our lab used the official ZIP package in private server staging. We checked the extracted WordPress core files against official checksums before making the completed installation available.
4. Configure the database and install
For the browser method described in the official installation guide, open the installation URL for the chosen folder. Supply the database details privately when prompted, then set your site title, administrator account and email. Use a strong unique administrator password and save it securely. Avoid screenshots containing passwords or configuration secrets.
If WordPress cannot create wp-config.php, configure that file securely using the official instructions. Never make it world-writable as a general workaround.
How our lab completed this step
We completed configuration and database installation with WP-CLI from the server, rather than entering a new administrator credential into the browser installer. This guide does not claim that the browser installation form was tested end to end.
An operator using WP-CLI should use the intended site's path and explicit URL, provide credentials privately, and check siteurl/home after moving a staged installation. We set both to the final HTTPS /wordpress address. Credentials are kept out of the public guide.
5. Check the installed site
Open the site's HTTPS URL and the wp-login.php page in its installation folder. Check that internal links point to the correct hostname and folder, and that styles and images load.
Original AdminsForum WordPress Tutorial Lab after installation on aaPanel Free Edition.
For your own site, log in and check the dashboard, save a draft, upload a small test image and verify the functions you need. A homepage response alone is not a full application acceptance test. Confirm outgoing email separately before relying on password-reset or notification messages.
6. Choose permalink rules separately
The lab initially uses plain query-string permalinks. If you enable pretty permalinks, configure the matching WordPress rewrite rules for your web server and installation folder, then test a post URL. Nginx does not apply Apache .htaccess rules. Do not paste a root-directory rewrite into a subfolder installation without adapting it.
7. Basic checks after installation
Keep WordPress, themes and plugins updated after compatibility checks and backups.
Remove unused plugins/themes and use only trusted sources.
Take both file and database backups and test recovery.
For a tutorial/staging site, discourage search indexing and use stronger access restrictions if it contains private data. A search-indexing preference is not access control.
Verify email delivery separately; it was not configured or tested in our lab.
Common problems
Error establishing a database connection: check database name, user, password, host and the database service.
Blank page or fatal error: inspect PHP logs and extension/application compatibility.
Wrong links after moving files: check WordPress Address/siteurl and Site Address/home.
Pretty permalinks return 404: verify the correct web-server rewrite rules for the actual installation folder.
Uploads fail: check ownership, permissions, PHP upload limits and free space without using 777 as a blanket fix.
Verified on 10 October 2026
Our lab installed WordPress 7.1.3 from the official ZIP, verified core checksums, configured a dedicated local database and completed installation with WP-CLI. The website runs on aaPanel Free Edition 8.0.6 with PHP 8.5.11 and MariaDB 10.11. The final HTTPS homepage and login page both returned HTTP 200, and homepage links used the correct /wordpress address. On 11 October 2026 we also verified administrator browser login and uploaded an original test image through the WordPress media uploader. Mail delivery and pretty permalinks remain separate checks.
Quick answer
To upload a website file with aaPanel Free Edition, open Files, navigate to the website's document root, click Upload → Upload File, select the file, then click Confirm Upload. Open the corresponding HTTPS URL to check the result.
Before uploading
Have a working website/domain and SSL certificate. Confirm its document root in Website → site settings → Directory. Back up existing files before replacing anything. This tutorial uses a harmless HTML page with a new filename so it does not replace the homepage.
1. Open the correct site folder
Click Files. Navigate to your site's document root. In our lab we opened wwwroot and then the dedicated lab domain folder. Do not upload into the general server folder or another website's directory.
2. Prepare a simple test file
Create a local file named adminsforum-file-manager-demo.html with your editor. A minimal test is:
Save it as .html, not .html.txt. Our screenshot uses an original styled AdminsForum demo page.
3. Upload the file
Click Upload in File Manager.
In the Upload File dialog, click Upload File and select your local file.
Check the filename and size. At this stage the upload can still show Not Started.
Click Confirm Upload. Selecting the file alone does not finish the upload.
Wait until the transfer finishes, then confirm the filename appears in the site's file list.
If an overwrite prompt appears, check that replacing that exact file is intended and that a backup exists. Do not overwrite configuration files accidentally.
Original AdminsForum lab page after upload through aaPanel File Manager, verified over HTTPS.
5. Understand homepage filenames
This test file has its own URL. It does not become the homepage automatically. The site's Default document setting controls which index file loads for a directory. Before replacing an existing index.html or index.php, back it up and check how your application starts. A full CMS or framework also needs its application configuration, dependencies and database.
Common problems
404 Not Found: check the exact filename, capitalization, domain and document root. Confirm the upload finished.
403 Forbidden: check permissions, file ownership and access rules. For a directory URL also check whether a default index file exists.
Old page still appears: open the exact new file URL and check browser/CDN caching and which index file is configured.
Missing images/styles: upload referenced assets into their matching folders and check relative paths.
PHP code displays as text: stop and investigate the site's PHP handler configuration before uploading sensitive PHP configuration files.
Do not use 777 permissions as a general fix. Keep files readable by the web server with the minimum permissions required by your application. Never place database dumps, private keys or backup archives in a public website directory.
What we verified
On 10 October 2026, we used aaPanel Free Edition 8.0.6 File Manager to select and upload a new original HTML file to the dedicated lab website. We clicked Confirm Upload, confirmed the file appeared, and opened its HTTPS URL successfully. The existing homepage was preserved. ZIP extraction and deploying a CMS are separate procedures.
![[Image: mail-domain-branded-20261011.png]](https://adminsforum.com/uploads/tutorials/mail-domain-branded-20261011.png)
![[Image: mail-install-branded-20261011.png]](https://adminsforum.com/uploads/tutorials/mail-install-branded-20261011.png)
![[Image: mail-environment-branded-20261011.png?v=1]](https://adminsforum.com/uploads/tutorials/mail-environment-branded-20261011.png?v=1)
![[Image: aapanel-log-404-tested-20261011.png?v=1]](https://adminsforum.com/uploads/tutorials/aapanel-log-404-tested-20261011.png?v=1)
