Cloudflare Tunnel Error 1033 means Cloudflare cannot find a healthy cloudflared connector for the tunnel associated with the requested hostname. The connector may have stopped, lost its outbound connection or become unavailable because the hostname points to an incorrect tunnel destination.
The fastest way to fix Error 1033 is to check the tunnel's connection status before changing anything else. Open the Cloudflare dashboard, go to Networking → Tunnels and locate the tunnel associated with the affected hostname. A Down or Inactive tunnel needs connector troubleshooting, while a Healthy tunnel returning Error 1033 requires a closer look at its DNS destination.
The important distinction is that Error 1033 does not automatically mean your internal application has stopped working. Restarting a web server, changing its listening port or modifying its SSL configuration may accomplish nothing when Cloudflare can not reach the tunnel itself.
Find the Failed Connection in Cloudflare
Cloudflare Tunnel uses an outbound connection established by cloudflared to connect an application or private network to Cloudflare. When someone opens a hostname configured to use that tunnel, Cloudflare must find an available connector before it can forward the request.
Error 1033 appears when that tunnel connection is unavailable for the requested hostname. The first useful evidence is therefore the status of the tunnel, not the response of the application running behind it.
Open Networking → Tunnels in your Cloudflare account and check the tunnel's status.
| Tunnel status | What it tells you | Recommended action |
|---|---|---|
| Healthy | The tunnel has established its expected Cloudflare connections | Check whether the hostname points to this tunnel |
| Inactive | The tunnel was created but has never connected | Install or start the intended connector |
| Down | The tunnel was previously connected but is now disconnected | Inspect the connector process and its logs |
| Degraded | Some connector connections have failed but the tunnel is still serving traffic | Examine connection logs and network restrictions |
My recommended troubleshooting order is to separate missing connections from incorrect routing. If the tunnel is Down, investigate why cloudflared disconnected. If it is Healthy, verify that the hostname actually references that tunnel instead of restarting a working connector.
A Degraded status needs a different interpretation because Cloudflare can still serve traffic through the remaining connections. It is evidence of reduced tunnel availability, but it does not prove that every request should return Error 1033.
Also verify that you are examining the correct tunnel. An account may contain several tunnels, and seeing one Healthy tunnel does not establish that the failing hostname is assigned to it.
Restore a Tunnel That Has Never Connected
An Inactive tunnel indicates that Cloudflare has a tunnel configuration but has not received an established connection from its connector.
This commonly occurs when someone creates a tunnel through the dashboard but does not complete the connector installation. It can also happen when cloudflared was installed but never started with the credentials associated with the intended tunnel.
Select the Inactive tunnel in Networking → Tunnels and open its Overview page. Cloudflare provides an Add a replica option with installation instructions for connecting another cloudflared instance to that tunnel.
For a remotely managed tunnel, use the token and installation instructions associated with the correct tunnel. For a locally managed tunnel, verify that its configuration and tunnel credentials reference the intended tunnel identifier.
Avoid creating another tunnel merely because the existing one has never connected. Doing so can leave the original hostname pointing toward an inactive destination while a newly created tunnel appears Healthy elsewhere in the account.
Once the connector starts successfully, confirm that Cloudflare reports an active connection. If the status becomes Healthy but the hostname still returns Error 1033, the remaining investigation should focus on the hostname's tunnel destination.
For an installation that has not yet been configured correctly, BusinessTally's guide to publishing an internal app using Cloudflare Tunnel covers the initial connector and hostname setup. The steps below focus on recovering a tunnel that was already configured.
Repair a Tunnel That Has Gone Down
A Down tunnel was connected previously but is no longer connected to Cloudflare. The immediate task is to establish whether cloudflared stopped running or is running without successfully establishing a connection.
That distinction prevents unnecessary configuration changes. A stopped service may need a startup correction, while an active process repeatedly reporting connection failures needs further network investigation.
Check the Connector Service on Linux
If cloudflared runs as a systemd service on Linux, inspect its current state:
sudo systemctl status cloudflared --no-pager
The result indicates whether the service is active, inactive or failed. An inactive service may have been stopped, while a failed service generally requires examining the reason its startup or execution failed.
Retrieve the recent service logs:
sudo journalctl -u cloudflared -n 100 --no-pager
Look for the errors immediately preceding the disconnection or failed startup. Missing configuration files, inaccessible credentials and network connection failures require different corrections, so the logs should guide the next action.
If the configuration is intact and the service has simply stopped, restart it:
sudo systemctl restart cloudflared
Check the result:
sudo systemctl status cloudflared --no-pager
A service returning to active (running) is encouraging but it does not prove the tunnel has reconnected. Return to Cloudflare and confirm that the expected tunnel changes to Healthy.
If the service fails again immediately, inspect the new log entries rather than repeating the restart. A recurring failure suggests that restarting temporarily or unsuccessfully addresses the symptom without correcting its cause.
Inspect a Connector Running in Docker
For Docker installations, the cloudflared process runs inside a container rather than necessarily existing as a service on the host.
Start by checking the containers:
docker ps -a
Identify the container running cloudflared and inspect its recent logs:
docker logs --tail 100 <container_name>
Replace <container_name> with the actual container name or ID. The logs can help distinguish a container that exited because of a startup problem from one that remains running but can not establish connections to Cloudflare.
If the container is stopped, determine why it exited before restarting it through your existing Docker or Compose deployment. If it remains running, focus on connection errors rather than assuming the tunnel is available.
An active container and a Healthy tunnel are not equivalent observations. Docker confirms that a process exists, while Cloudflare's tunnel status indicates whether the required network connections have been established.
Check Whether the Failure Happens After a Reboot
If Error 1033 consistently appears after the server restarts, investigate whether the connector is configured to start automatically.
On a Linux installation using systemd, run:
systemctl is-enabled cloudflared
If the service is disabled and its existing configuration is correct, enable automatic startup:
sudo systemctl enable cloudflared
Enabling the service does not immediately start a stopped connector or repair invalid credentials. It ensures that systemd attempts to start the service during subsequent boots.
A service that starts successfully when launched manually but fails during boot may also be using a different configuration path or encountering startup dependencies. Compare its startup logs with the working configuration before changing any tunnel credentials.
Diagnose a Running Connector That Can not Connect
A running cloudflared process can still fail to establish the outbound connections that Cloudflare Tunnel requires.
The connector may repeatedly attempt to resolve Cloudflare endpoints, establish QUIC connections or fall back to HTTP/2. Those failures can leave the tunnel unavailable even though the service manager reports that its process is running.
Cloudflare provides a diagnostic command that helps inspect the connector and its environment:
cloudflared tunnel diag
Check the installed version first:
cloudflared --version
Cloudflare supports tunnel diagnostic reports in cloudflared version 2024.12.2 and later. Beginning with version 2026.5.2, Cloudflare also introduced automated startup connectivity checks covering DNS resolution, UDP and TCP connectivity on port 7844 and access to its management API.
The diagnostic command can collect connection information and generate a ZIP report when its required diagnostic interfaces are available. If the connector has completely stopped, some tunnel-specific information may be unavailable, making the service logs and startup output the better initial evidence.
The useful result is not simply whether the diagnostic command completes. Look at which check fails and compare it with the actual connection errors. A DNS resolution problem calls for a different fix than a successful DNS lookup followed by blocked outbound traffic.
Fix Cloudflare Endpoint DNS Resolution Failures
One error documented by Cloudflare begins with:
edge discovery: error looking up Cloudflare edge IPs
This indicates a failure while resolving the Cloudflare endpoints required to establish tunnel connections. A corporate DNS resolver, incorrect local DNS configuration or container-level resolver problem can prevent cloudflared from obtaining the necessary records.
For that specific edge-discovery error, Cloudflare documents the following SRV lookup:
dig SRV _v2-origintunneld._tcp.argotunnel.com
If the response reports SERVFAIL, NXDOMAIN, or an empty answer, compare it with Cloudflare's public resolver:
dig SRV _v2-origintunneld._tcp.argotunnel.com @1.1.1.1
If the public resolver succeeds while the locally configured resolver fails, investigate the local DNS configuration. The resolver may be blocking the required record type or failing to forward the query correctly.
If both queries fail, check whether DNS requests are being blocked by a firewall or network security policy. Do not immediately replace the tunnel's public CNAME record, because the failure concerns the connector's ability to discover Cloudflare endpoints.
For newer connectivity checks, Cloudflare also documents A-record lookups against its regional tunnel endpoints:
dig A region1.v2.argotunnel.com
dig A region2.v2.argotunnel.com
These commands apply to the standard global tunnel region. Use the appropriate regional endpoints when your tunnel is configured for a different Cloudflare region.
Successful lookups establish that the resolver can obtain endpoint addresses but they do not prove that the connector can connect to those addresses. If DNS succeeds and Error 1033 continues, inspect the transport connection results.
Fix QUIC Connection Failures on Port 7844
Another documented message is:
Failed to dial a quic connection
It may appear alongside a message indicating that the QUIC handshake did not complete before its timeout. In this situation, the connector resolved Cloudflare's endpoint addresses but could not complete the required connection over UDP.
Cloudflare Tunnel uses outbound port 7844 for its connection protocols. QUIC uses UDP, while HTTP/2 provides a TCP-based alternative.
The important diagnostic question is whether the connector successfully switches to HTTP/2 after the QUIC failure.
Cloudflare documents the following fallback message:
Switching to fallback protocol http2
If that fallback completes successfully and the tunnel becomes Healthy, the blocked QUIC connection may no longer prevent the hostname from working. The original UDP restriction still deserves investigation but it should not be confused with a continuing Error 1033 condition.
A connector configured to force QUIC will not be able to use the TCP fallback when UDP is blocked. In that situation, either permit the required outbound UDP traffic or correct the forced protocol configuration.
If no protocol establishes a working connection, continue by testing connectivity to Cloudflare's tunnel endpoints.
Test TCP and UDP Connectivity
Cloudflare's connectivity documentation uses nc, also known as netcat, to check outbound connections on port 7844.
First, obtain an endpoint IP address from the appropriate regional DNS lookup. For the standard global region, you can use:
dig A region1.v2.argotunnel.com
Choose one of the returned IPv4 addresses for the following tests. The example address below appears in Cloudflare's documentation but you should use an address returned by your own lookup.
Test UDP connectivity:
nc -uvz -w 3 198.41.192.167 7844
Test TCP connectivity:
nc -vz -w 3 198.41.192.167 7844
The TCP result helps identify whether a connection can be established to the selected destination. UDP tests are less conclusive because UDP does not establish connections through a TCP-style handshake, so interpret their output alongside the connector's actual QUIC results.
The following comparison shows how the results should guide the next action.
| Connectivity result | What it suggests | Appropriate next action |
|---|---|---|
| TCP and UDP appear available | The tested network path permits both protocols | Examine other connector startup or configuration errors |
| TCP works, UDP fails | HTTP/2 may work while QUIC is blocked | Allow UDP or use the supported TCP fallback |
| UDP works, TCP fails | QUIC may work while HTTP/2 is unavailable | Allow TCP or avoid forcing HTTP/2 |
| Both fail | Outbound tunnel connectivity may be blocked | Review firewall, hosting and upstream network restrictions |
If both protocols fail, inspect the firewall policies applied to the server and its network. Cloudflare documents the required tunnel destinations and outbound rules, which should be used instead of opening unrelated ports.
For a VPS or cloud-hosted server, check both the operating system firewall and the hosting provider's security rules. A local firewall may permit traffic while an upstream security group or network policy blocks it.
Do not confuse outbound tunnel connectivity with inbound web server connectivity. Cloudflare Tunnel establishes connections outward from the connector, so opening inbound HTTP ports on the private application will not repair a blocked connection to Cloudflare.
Fix Error 1033 When the Tunnel Is Healthy
A Healthy tunnel changes the troubleshooting direction because Cloudflare already has working connections to that tunnel.
If a particular hostname still returns Error 1033, verify that its DNS record references the tunnel you inspected. The relevant problem may be an outdated or incorrect destination rather than a disconnected connector.
Cloudflare assigns a unique identifier to each named tunnel. In the standard Cloudflare environment, the associated CNAME destination follows this format:
<UUID>.cfargotunnel.com
Replace <UUID> with the actual identifier of the intended tunnel.
Open DNS → Records for the affected domain and locate the record matching the failing hostname. Compare its configured destination with the identifier of the Healthy tunnel.
Consider a server migration where an administrator replaces an old Cloudflare Tunnel with a new one. The new tunnel may establish healthy connections while the existing hostname continues pointing to the previous tunnel's identifier.
If that previous tunnel is disconnected or no longer exists, Cloudflare may be unable to route the hostname through a healthy connector. Restarting the new connector can not correct the outdated DNS destination because the hostname still references the old tunnel.
The appropriate correction is to associate the hostname with the intended operational tunnel. Verify which tunnel should receive the traffic before changing the record, particularly when several applications share the same Cloudflare account.
Check the CNAME Destination After Replacing a Tunnel
Replacing a tunnel does not mean every related hostname will necessarily point to the replacement automatically.
Review the affected hostname's CNAME target and compare it with the new tunnel's identifier. If they differ, determine whether the original tunnel is still intended to serve the application or whether the hostname needs to be assigned to the replacement.
Avoid deleting working DNS records or recreating tunnels without establishing that relationship. An unnecessary replacement can create additional routing confusion, especially when multiple hostnames use different published application routes.
Cloudflare also has a specific requirement for accounts operating in its FedRAMP High environment. Their tunnel CNAME destinations use:
<UUID>.fed-cfargotunnel.com
A FedRAMP High hostname pointing to the standard .cfargotunnel.com destination can return Error 1033 even when its tunnel is Healthy. This requirement applies to that environment and should not be copied into ordinary Cloudflare Tunnel configurations.
After correcting the destination, confirm that the hostname references the intended tunnel and test access again. A Healthy status alone is not enough to verify the change because it describes the connector's connection, not the hostname's complete routing configuration.
Verify That Error 1033 Is Resolved
A successful repair should produce two separate results: the intended tunnel should have a healthy connection to Cloudflare and the affected hostname should no longer return Error 1033.
First, open Networking → Tunnels and confirm the connection status. If the tunnel remains Down or Inactive, the connector problem has not been resolved even if its service appears to be running locally.
Next, test the actual hostname:
curl -i https://app.example.com/
Replace app.example.com with the hostname that previously displayed Error 1033. Examine the response to determine whether Cloudflare can now route the request to the intended destination.
An application page, expected authentication response or valid redirect can indicate that the tunnel is routing requests again. However, receiving a different error does not prove that the application itself is fully functional.
For example, a tunnel-related 502 Bad Gateway can indicate that Cloudflare reached the connector but the connector could not reach the internal service. That is a different failure from Error 1033 and should not lead you back into unnecessary tunnel connection changes.
For services that disconnect intermittently, compare the time of the reported failure with connector logs and tunnel status changes. Repeated disconnections after a successful restart suggest that the underlying network, process or startup problem may remain unresolved.
The most reliable fix is the one that matches the observed failure. Restore a stopped connector, correct blocked outbound connectivity when the connector can not establish a connection or repair the hostname's tunnel destination when its assigned tunnel is wrong.
Once the intended tunnel remains Healthy and the affected hostname consistently responds without Error 1033, the missing tunnel connection problem has been resolved.
