Guide Configure Cloudflare Tunnel in aaPanel

Guide Configure Cloudflare Tunnel in aaPanel - Printable Version

+- AdminsForum (https://adminsforum.com)
+-- Forum: Free & open-source control panels (https://adminsforum.com/Forum-free-open-source-control-panels)
+--- Forum: aaPanel (https://adminsforum.com/Forum-aapanel)
+---- Forum: aaPanel Guides & Tutorials (https://adminsforum.com/Forum-aapanel-guides-tutorials)
+----- Forum: aaPanel Plugins & Integrations Guides (https://adminsforum.com/Forum-aapanel-plugins-integrations-guides)
+----- Thread: Guide Configure Cloudflare Tunnel in aaPanel (/Thread-guide-configure-cloudflare-tunnel-in-aapanel)

Configure Cloudflare Tunnel in aaPanel - DEV - 10-11-2026

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:

Code:

curl -I -H 'Host: tunnel-test.example.com' http://127.0.0.1:80

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:

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.

Saving a DNS token is not proof that tunnel CLI login is ready. Likewise, browser authorization does not prove the token can edit DNS.

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.

A local HTTP service behind the connector is different from the public HTTPS address visitors use. If you choose an HTTPS origin, validate its certificate and hostname/SNI rather than disabling certificate verification as a default fix.

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 validate

Use the Advanced service controls to install/start the service when needed, then check its actual state:

Code:

systemctl is-active cloudflared
journalctl -u cloudflared -n 50 --no-pager

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:

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.

Publishing a website through a tunnel does not automatically create a Cloudflare Access login policy. This walkthrough maps a public test website; administration/private applications need a separate access-control design.

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.

Restore recorded DNS/configuration values deliberately if abandoning the test. Do not delete unrelated records to clear an error.

Guide sequence: Installation → this configuration walkthrough → version-specific fixes.

References: Plugin source and author instructions · Cloudflare locally managed tunnel guide · Cloudflare credential permissions.