An internal web application running at an address such as http://localhost:3000 is normally accessible only from its host computer or local network. Cloudflare Tunnel lets you expose that application through a public hostname without opening inbound router ports or requiring visitors to connect directly to your server.
To configure it, create a Cloudflare Tunnel, install the cloudflared connector and connect your public hostname to the application's internal address. Cloudflare receives incoming requests and forwards them through the tunnel to the service running inside your network.
The application must already be working locally, and the tunnel connector must be able to reach it. If the application is intended only for employees or administrators, you should also restrict access before publishing its hostname.
Confirm Your Internal Application Is Running
Before creating a tunnel, verify that your application responds at its local address. A working tunnel cannot deliver an application that has stopped or is listening on the wrong port.
For this example, assume you have an application running on port 3000 and want to publish it through app.example.com.
| Configuration | Example |
|---|---|
| Internal application | Web application on port 3000 |
| Internal address | http://127.0.0.1:3000 |
| Public hostname | app.example.com |
| Cloudflare connector | cloudflared |
| Inbound router port forwarding | Not required |
The hostname and address are illustrative. Your configuration must use the actual address that the Cloudflare connector can reach.
Test the Local Service
Open a terminal on the computer running your application and execute:
curl -i http://127.0.0.1:3000/
If the application is running, the command should return an HTTP response. A successful page response or an expected redirect indicates that the local service is responding, although you should confirm that it serves the intended application.
If the connection is refused, check whether the application has started and is listening on port 3000. Resolve that issue before configuring Cloudflare Tunnel, because the connector will need to reach the same service.
Use the Correct Address for cloudflared
The internal address depends on where cloudflared runs relative to your application.
If the connector and application run directly on the same computer, http://127.0.0.1:3000 is generally appropriate. If they run on different machines, the connector needs the application's reachable local network address.
For example, an application on another computer might be accessible at http://192.168.1.50:3000. You should test that address from the machine running cloudflared, rather than assuming an address that works on the application server will work everywhere.
Docker introduces another distinction because localhost inside a container refers to that container's own network environment. If the connector runs in Docker, use the correct container-network hostname or other reachable service address.
This check prevents a common configuration failure: Cloudflare successfully connects to the tunnel but the connector cannot reach the application behind it.
Create and Connect a Cloudflare Tunnel
Cloudflare supports remotely managed tunnels that can be configured through its dashboard. This allows you to manage the tunnel and its published application routes without maintaining a separate local routing configuration file.
You need a Cloudflare account, a domain configured with Cloudflare and access to the computer that will run cloudflared.
Create the Tunnel
Sign in to the Cloudflare dashboard.
Navigate to Networking → Tunnels.
Select Create Tunnel.
Enter a descriptive name, such as
internal-web-app.Select Create Tunnel.
Choose the operating system and architecture of your connector host.
Copy the installation and run commands displayed by Cloudflare.
Execute those commands on the machine that can reach your internal application.
Cloudflare provides installation instructions for different environments, including Linux, Windows, macOS and Docker. Use the command generated for your operating system rather than substituting instructions intended for another platform.
The command for a remotely managed tunnel includes an authentication token. Keep that token private because it authorizes a connector to establish connections for your tunnel.
Verify the Tunnel Connection
After installing and starting cloudflared, return to the Cloudflare dashboard and check the tunnel's connection status.
A Healthy status indicates that Cloudflare has an active connection to the connector. At this stage, the tunnel is connected but the application is not necessarily accessible because its public route still needs to be configured.
If the tunnel remains Inactive or Down, confirm that the connector is running and has outbound internet access. Cloudflare Tunnel uses outbound connections on port 7844, with supported connections using UDP or TCP depending on the selected transport.
Your router does not need an inbound forwarding rule for application port 3000. The connector establishes the connection outward to Cloudflare, which then uses that connection to deliver requests to the internal service.
Protect a Private Application Before Publishing
Cloudflare Tunnel provides a connection to an internal application, but it does not automatically make that application accessible only to authorized users.
If you publish an administrative dashboard without access restrictions, its public hostname may be reachable by anyone on the internet. For applications containing private information, configure Cloudflare Access before creating the published application route.
In the Cloudflare dashboard, open Zero Trust → Access controls → Applications and create a new application. Select the option for a self-hosted application and configure the public hostname you intend to use, such as app.example.com.
Create an Allow policy identifying the people who should be able to access it. Depending on your authentication configuration, the policy can use specific email identities or an appropriate identity provider.
For example, an internal dashboard intended for two administrators should permit only those authorized identities. Completing an authentication process should not automatically provide access to everyone who can sign in.
Cloudflare Access denies requests that do not match an applicable Allow policy. After creating the Access application, you can also configure the tunnel's Protect with Access option to validate Access tokens before requests reach the internal service.
If the application is intentionally public, Access authentication may not be necessary. However, applications originally designed for private network use should be reviewed carefully before exposing them through a public hostname.
Publish the Application Through the Tunnel
Once the connector is connected and the required access policy is configured, create a published application route.
This route associates the hostname visitors will open with the internal service that should receive their requests.
Add the Published Application Route
Open Networking → Tunnels in Cloudflare.
Select the tunnel you created.
Open the Routes tab.
Select Add route → Published application.
Enter the hostname you want to publish.
Set Service URL to the application's internal address.
Select Add route to save the configuration.
For the example application, the settings are:
| Setting | Value |
|---|---|
| Route type | Published application |
| Subdomain | app |
| Domain | example.com |
| Service URL | http://127.0.0.1:3000 |
| Public hostname | https://app.example.com |
The public hostname is the address visitors enter into their browsers. The Service URL is the destination that cloudflared uses after receiving the request through the tunnel.
For this example, visitors open https://app.example.com, while the connector forwards their requests to http://127.0.0.1:3000.
The browser-to-Cloudflare connection uses HTTPS, even though the local application in this example uses HTTP. The internal service is reached through the connector rather than through an inbound router port.
If your application already serves HTTPS internally, enter its HTTPS address instead. The connector must be able to establish that connection and validate the origin's certificate using the appropriate TLS settings.
Verify the Tunnel DNS Record
For domains using Cloudflare's full DNS setup, creating a published application route normally creates the associated DNS record automatically.
Open DNS → Records and locate the hostname you published. The record generally resembles the following configuration:
| DNS setting | Expected value |
|---|---|
| Type | CNAME |
| Name | app |
| Target | <tunnel-UUID>.cfargotunnel.com |
| Proxy status | Proxied |
Cloudflare generates the tunnel UUID, which identifies the destination associated with your tunnel.
If Cloudflare reports that an A, AAAA or CNAME record already exists for the hostname, inspect that record before making changes. It may belong to an existing application and replacing it without checking could disrupt another service.
Also verify that the intended tunnel hostname has not been switched to DNS-only as part of an earlier configuration change. A published application route depends on Cloudflare handling the traffic, so an unintended proxy change can break that connection.
If the hostname was previously modified while disabling Cloudflare for a website, check the existing DNS configuration and restore the appropriate proxied tunnel route.
For domains using Cloudflare's partial CNAME setup, DNS records are managed differently. In that situation, follow Cloudflare's partial-setup instructions for creating the necessary record at your authoritative DNS provider.
Test the Public Application
After saving the route, open the application through its public hostname:
https://app.example.com
If Cloudflare Access is enabled, the browser should present the configured authentication process. An authorized user should be able to sign in and reach the internal application.
For an intentionally public application, the expected behaviour is that the application loads directly without an Access login requirement.
Verify Access From Another Network
Test the hostname from a device outside the network hosting your application. For example, open it on a phone using mobile data rather than the same Wi-Fi connection as the application server.
This verifies that the public hostname can deliver the application through Cloudflare instead of relying on local network access.
For an Access-protected application, perform a second check using an unauthorized identity. That user should be denied access, while someone matching the Allow policy should be able to reach the application.
Also test the application's main functions after signing in. A successful homepage load does not establish that navigation, authentication redirects or other application requests behave correctly.
Check Application Redirects
Some applications generate links or redirects using a configured base URL. If that setting still contains http://localhost:3000, visitors may be redirected to an address that exists only on the original computer.
For example, the application may load through Cloudflare but redirect to localhost after a user signs in. The tunnel is working in that situation but the application is generating an unsuitable external URL.
Check whether your application provides a public URL or base URL setting. Where supported, configure it to use https://app.example.com and test the affected workflow again.
This adjustment belongs to the application configuration rather than the tunnel connection itself. Cloudflare Tunnel forwards requests but does not automatically replace every URL generated by the internal application.
Diagnose Failed Tunnel Connections
If the published hostname does not load, determine whether the failure occurs between Cloudflare and the connector or between the connector and the internal application.
The distinction matters because a connected tunnel can still return errors when its Service URL points to an unavailable application.
| What happens | Likely cause | Corrective action |
|---|---|---|
| Tunnel is Inactive | Connector has not established a connection | Start and connect cloudflared |
| Tunnel is Down | Previously connected connector has disconnected | Check the connector service and network |
| Cloudflare Error 1033 | No healthy connector is available or tunnel routing is incorrect | Check tunnel health and DNS destination |
| Tunnel-related 502 Bad Gateway | Connector cannot reach the internal service | Verify Service URL, port and protocol |
| Access login is denied | User does not satisfy the Access policy | Check permitted identities |
| Application redirects to localhost | Incorrect application base URL | Update the application's public URL |
| Application fails after a restart | Connector or application did not restart | Check service startup configuration |
These symptoms help narrow down the failure without changing unrelated Cloudflare settings. Start with the component identified by the error and confirm whether it is responding before making another change.
Error 1033: Cloudflare Can not Reach the Tunnel
Cloudflare Error 1033 generally indicates that Cloudflare cannot find a healthy connector for the requested tunnel.
Open Networking → Tunnels and inspect the connection status. If the tunnel is Down, check whether the cloudflared process is running and whether the host can establish outbound connections.
For a Linux installation using a systemd service, run:
sudo systemctl status cloudflared
If the service has stopped or failed, review its logs to identify the reason. A service restart may restore connectivity but repeated failures require investigating the underlying process or network restriction.
If the tunnel is Healthy but the public hostname still returns Error 1033, verify that its DNS record points to the intended tunnel. An incorrect tunnel destination can prevent Cloudflare from routing the request to the connector you configured.
Error 502: The Connector Can not Reach the Application
A tunnel-related 502 Bad Gateway error stating that the origin service cannot be reached usually means the tunnel is connected but the connector can not contact the internal application.
For example, your route might point to http://127.0.0.1:3000 while the application is actually running on port 8080. Cloudflare receives the request but the connector can not reach the configured destination.
Test the Service URL from the environment running cloudflared:
curl -v http://127.0.0.1:3000/
If the connection is refused, confirm that the application is running and that the configured port is correct. If the application runs on another machine, test its reachable LAN address from the connector host instead.
Also verify that the Service URL uses the correct protocol. An application expecting HTTPS may fail when the tunnel route is configured with http://, even when the hostname and port are otherwise correct.
If the internal service uses HTTPS and the connector reports a certificate-validation error, check the certificate hostname and trust configuration. Correcting the origin TLS settings is preferable to permanently disabling certificate verification.
The Application Stops Working After Restart
A tunnel can work during initial setup but become unavailable after the computer hosting it restarts.
This often happens when either cloudflared or the internal application was started manually and does not automatically run when the machine boots.
Check that the connector is installed as an appropriate operating-system service and that the application has its own reliable startup configuration. Both must be running for the published hostname to deliver the application.
After correcting the startup behaviour, restart the host and test the public hostname again. A successful connection after reboot confirms that the application no longer depends on manually starting the connector or web server.
Confirm the Application Is Accessible
The setup is complete when the public hostname consistently loads the intended internal application through Cloudflare Tunnel without requiring inbound router port forwarding.
Verify that the connector remains connected, the published route points to the correct internal service and the application's essential functions work from outside the local network. For private applications, confirm that authorized users can authenticate while unauthorized users are denied.
A final test after restarting the connector host helps establish that the configuration remains available during normal operation.
Cloudflare Tunnel provides the connection between the public hostname and the internal application. When the connector, published route and application address are configured correctly, visitors can reach the service through Cloudflare without connecting directly to an exposed origin port.
