This is the next guide after installing the Cloudflare Tunnel plugin in aaPanel.
We will connect one test website to a public hostname using fdciabdul's community plugin. The example hostname is tunnel-test.example.com: replace it everywhere with a subdomain of your own Cloudflare-managed domain.
Verification scope: Plugin controls and behavior are based on source commit ff0c7359f050fbca2b9efab11b61aa462d65b2d0 (metadata 1.3.0), checked against Cloudflare's documentation. Live plugin installation, account authorization and end-to-end screenshots remain pending. This is a written setup walkthrough, not a claim that our lab tunnel is already running.
1. Prepare the test website first
Open aaPanel → Website and create or select a harmless test website bound to your chosen hostname. Put an identifiable test page in its document root, for example “AdminsForum tunnel test.” Use the web server and listening port that actually serve this website.
For a local HTTP origin on port 80, open Terminal and check:
Replace the hostname. The response must belong to the intended site. A connection refusal means the local server/port needs fixing first. A default website means its hostname binding needs checking. An unexpected redirect needs investigating before adding the tunnel.
Why this comes first: Cloudflare forwards requests to the origin you configure. It cannot repair an incorrect local website or missing web server.
2. Check the Cloudflare zone
Your domain must be active in Cloudflare with its authoritative nameservers set correctly. Decide on a dedicated unused test subdomain. Inspect its DNS records before proceeding and record any existing values you need to preserve.
Do not reuse a hostname serving an existing website or mail service. The reviewed plugin has DNS conflict and cleanup limitations described in our plugin review and fixes.
3. Configure the account profile and credentials
Open Cloudflare Tunnel in aaPanel, then its credentials/profile section. Give the profile a recognizable name, such as AdminsLab.
There are two separate credentials in this locally managed workflow:
For the DNS token, use zone-scoped permissions suitable for the plugin's zone lookup and DNS edits, limited to the intended test zone. Its code lists zones and modifies records; verify both operations instead of relying only on a token-valid response. Avoid giving unrelated domains to the token.
Use the plugin's Login/Get login URL control for the intended profile, follow the Cloudflare browser authorization, then return and check the result. Protect tokens, login links and certificate files; redact them in screenshots.
If Login reports “Profile not found”: an empty profile is filtered out by the reviewed upstream lookup. Stop and follow the version-specific fix article linked above. Do not keep creating duplicate profiles.
4. Create a locally managed tunnel
In the tunnel section, select the authorized profile and enter a unique name such as adminsforum-lab. Use Create & use, or Create followed by Use if your installed build separates those actions.
Record the returned tunnel UUID and confirm the selected profile. Tunnel creation generates credentials; it does not by itself establish a running connector.
Start with a fresh locally managed test tunnel. A tunnel managed through the Cloudflare dashboard can obtain its ingress remotely and ignore the local configuration this plugin writes. Mixing both management approaches makes troubleshooting confusing.
5. Add the hostname mapping
In the hostnames/ingress section:
In Cloudflare DNS, verify a proxied CNAME for the chosen hostname pointing to the selected UUID's cfargotunnel.com target. Do not create a second competing A/AAAA record for that same tunnel hostname.
6. Verify configuration and the connector service
The plugin writes its local configuration to /etc/cloudflared/config.yml. Review the tunnel ID, credentials path, intended hostname/service and final fallback rule. Avoid posting the credentials file itself.
Validate the generated ingress:
Use the Advanced service controls to install/start the service when needed, then check its actual state:
Expected checkpoint: ingress validation succeeds, the intended service is active and its logs show successful connector registration. A saved row or an “apply succeeded” message alone is insufficient: the reviewed upstream code can miss restart failures.
7. Open the public website
Open https://tunnel-test.example.com using your own hostname. Verify the identifiable page from step 1, not merely a response from any website.
Check these independently:
8. Troubleshoot the failing checkpoint
Guide sequence: Installation → this configuration walkthrough → version-specific fixes.
References: Plugin source and author instructions · Cloudflare locally managed tunnel guide · Cloudflare credential permissions.
We will connect one test website to a public hostname using fdciabdul's community plugin. The example hostname is tunnel-test.example.com: replace it everywhere with a subdomain of your own Cloudflare-managed domain.
Verification scope: Plugin controls and behavior are based on source commit ff0c7359f050fbca2b9efab11b61aa462d65b2d0 (metadata 1.3.0), checked against Cloudflare's documentation. Live plugin installation, account authorization and end-to-end screenshots remain pending. This is a written setup walkthrough, not a claim that our lab tunnel is already running.
1. Prepare the test website first
Open aaPanel → Website and create or select a harmless test website bound to your chosen hostname. Put an identifiable test page in its document root, for example “AdminsForum tunnel test.” Use the web server and listening port that actually serve this website.
For a local HTTP origin on port 80, open Terminal and check:
Code:
curl -I -H 'Host: tunnel-test.example.com' http://127.0.0.1:80Why this comes first: Cloudflare forwards requests to the origin you configure. It cannot repair an incorrect local website or missing web server.
2. Check the Cloudflare zone
Your domain must be active in Cloudflare with its authoritative nameservers set correctly. Decide on a dedicated unused test subdomain. Inspect its DNS records before proceeding and record any existing values you need to preserve.
Do not reuse a hostname serving an existing website or mail service. The reviewed plugin has DNS conflict and cleanup limitations described in our plugin review and fixes.
3. Configure the account profile and credentials
Open Cloudflare Tunnel in aaPanel, then its credentials/profile section. Give the profile a recognizable name, such as AdminsLab.
There are two separate credentials in this locally managed workflow:
- Browser-login certificate: supports the cloudflared CLI operations used to create/manage tunnels.
- DNS API token: lets the plugin discover the zone and automate its CNAME record.
For the DNS token, use zone-scoped permissions suitable for the plugin's zone lookup and DNS edits, limited to the intended test zone. Its code lists zones and modifies records; verify both operations instead of relying only on a token-valid response. Avoid giving unrelated domains to the token.
Use the plugin's Login/Get login URL control for the intended profile, follow the Cloudflare browser authorization, then return and check the result. Protect tokens, login links and certificate files; redact them in screenshots.
If Login reports “Profile not found”: an empty profile is filtered out by the reviewed upstream lookup. Stop and follow the version-specific fix article linked above. Do not keep creating duplicate profiles.
4. Create a locally managed tunnel
In the tunnel section, select the authorized profile and enter a unique name such as adminsforum-lab. Use Create & use, or Create followed by Use if your installed build separates those actions.
Record the returned tunnel UUID and confirm the selected profile. Tunnel creation generates credentials; it does not by itself establish a running connector.
Start with a fresh locally managed test tunnel. A tunnel managed through the Cloudflare dashboard can obtain its ingress remotely and ignore the local configuration this plugin writes. Mixing both management approaches makes troubleshooting confusing.
5. Add the hostname mapping
In the hostnames/ingress section:
- Enter your dedicated hostname, such as tunnel-test.example.com.
- Set the local service to http://127.0.0.1:80 only if that is the origin verified in step 1. Use the actual port for your website.
- Select the Cloudflare zone that owns the hostname and the appropriate profile where offered.
- Enable automatic CNAME creation only after checking that the hostname has no conflicting records.
- Save the mapping and read the complete result.
In Cloudflare DNS, verify a proxied CNAME for the chosen hostname pointing to the selected UUID's cfargotunnel.com target. Do not create a second competing A/AAAA record for that same tunnel hostname.
6. Verify configuration and the connector service
The plugin writes its local configuration to /etc/cloudflared/config.yml. Review the tunnel ID, credentials path, intended hostname/service and final fallback rule. Avoid posting the credentials file itself.
Validate the generated ingress:
Code:
cloudflared tunnel --config /etc/cloudflared/config.yml ingress validateCode:
systemctl is-active cloudflared
journalctl -u cloudflared -n 50 --no-pager7. Open the public website
Open https://tunnel-test.example.com using your own hostname. Verify the identifiable page from step 1, not merely a response from any website.
Check these independently:
- The correct local origin responds.
- The intended tunnel/profile is selected.
- DNS points to that tunnel.
- Ingress maps the hostname to the correct origin.
- The connector is actually running.
- The public page is the intended website.
8. Troubleshoot the failing checkpoint
- No zone listed: check account ownership and the token's zone scope/permissions, then refresh the zone list.
- Wrong website: check the aaPanel site binding and Host header. Use httpHostHeader only when deliberately required by the origin.
- Origin connection error: repeat the local request and check the service port.
- Certificate error for HTTPS origin: check certificate trust and SNI.
- Connector not connected: inspect service logs and outbound connectivity.
- Save/apply failed: inspect both DNS and configuration. Upstream rollback does not reliably restore every changed component.
Guide sequence: Installation → this configuration walkthrough → version-specific fixes.
References: Plugin source and author instructions · Cloudflare locally managed tunnel guide · Cloudflare credential permissions.