Troubleshooting

To investigate issues with a Spectrum application, use the logs and diagnostics described on this page. For API validation errors returned when creating or updating an application, refer to Error codes.

Spectrum event logs

Spectrum logs the lifecycle of every connection it proxies, including status codes for edge-to-origin failures (for example, 521 connection refused, 522 timeout, 523 unreachable). Refer to Event logs.

Virtual network origins

When a Spectrum application uses a virtual network origin, traffic to the origin flows through the connector associated with the virtual network. Diagnose origin connectivity from the connector side using the sources for your connector type.

Cloudflare Tunnel as the connector

• Tunnel logs record activity between cloudflared and Cloudflare's network and between cloudflared and your origin. Refer to Log streams.
• Tunnel diagnostic logs collect a diagnostic report from a single cloudflared instance. Refer to Diagnostic logs.
• Private network connectivity covers common causes when traffic does not reach a private origin through a tunnel. Refer to Private network connectivity.

Cloudflare WAN as the connector

For tunnel health, BGP, and routing diagnostics on WAN-connected origins, refer to Troubleshoot Cloudflare WAN.

Cannot create Spectrum application — DNS record already exists

Symptoms

• When creating a Spectrum application in the dashboard, you receive the error: "An A, AAAA or CNAME record already exists with that host."
• You already have a manually-created proxied DNS record (A, AAAA, or CNAME) for the hostname you are trying to use for a new Spectrum application.

Cause

Cloudflare does not support having both a manually-created proxied DNS record (A, AAAA, or CNAME) and a Spectrum application on the same hostname. This is because Spectrum provisions and manages its own DNS record for the application, which conflicts with the existing manually-created record. This is a platform limitation, not a dashboard-only restriction.

This limitation only applies to manually-created proxied records. Multiple Spectrum applications — including a mix of HTTP/HTTPS and TCP/UDP application types — can share the same hostname, because Spectrum manages the DNS record for each of them.

Solution

If you only need Spectrum applications on the hostname (for example, an HTTP/HTTPS Spectrum application alongside a TCP/UDP Spectrum application), you do not need a workaround — create the additional Spectrum application on the same hostname.

If you need to keep a manually-created proxied DNS record on the hostname (for example, to route standard HTTP/HTTPS traffic through the CDN and WAF instead of through Spectrum), use a split-hostname architecture instead, where the manually-created proxied record and the Spectrum application use different hostnames:

Traffic type	Hostname	Cloudflare service
HTTPS (web UI, APIs)	app.example.com	Manually-created proxied DNS record with CDN/WAF
TCP (custom protocol, ICA/HDX, and similar)	app-tcp.example.com	Spectrum application

Configure your application or client to use the appropriate hostname for each traffic type.

Common use case: Citrix Gateway / VDI

A common scenario where this limitation is encountered is Citrix Gateway deployments, where the web UI and authentication flow use HTTPS through a manually-created proxied record (requiring WAF protection) while ICA/HDX session traffic uses TCP on a different port through a Spectrum application. In this case, configure the Citrix StoreFront to generate ICA files pointing to the Spectrum hostname (for example, citrix-ica.example.com:4443) while keeping the web UI on the WAF-protected hostname (citrix.example.com:443).

For more details on this limitation, refer to Spectrum Limitations.

Origin receives HTTP instead of HTTPS (protocol mismatch)

Symptoms

• Your Spectrum application edge port uses HTTP (for example, port 8012), and your origin expects HTTPS on port 443.
• The origin rejects the connection or returns errors because it receives plaintext HTTP instead of encrypted HTTPS.
• The configuration appears to work as: http:8012 → Cloudflare Spectrum → http:443 (origin) instead of the expected http:8012 → Cloudflare Spectrum → https:443 (origin).

Cause

Spectrum operates at Layer 4 (TCP/UDP). When Edge TLS Termination is set to off (Passthrough), Spectrum forwards the raw TCP payload to the origin without modification. It does not perform protocol upgrade — connecting to an origin on port 443 does not automatically mean the connection will use HTTPS.

Solution

To send encrypted traffic from Cloudflare to your origin, you must turn on Edge TLS Termination on the Spectrum application and set it to Full or Full (Strict):

• Full: Cloudflare connects to origin using TLS but does not validate the origin certificate.
• Full (Strict): Cloudflare connects to origin using TLS and validates the origin certificate against a trusted CA or Cloudflare Origin CA.

You can configure Edge TLS Termination in the Spectrum application settings in the dashboard, or via the API by setting the tls field to full or strict.

Refer to Edge TLS Termination for more details.

TLS handshake failures (error 525)

Symptoms

• For TCP applications with Edge TLS Termination set to Full or Full (Strict): connections to the origin fail. Spectrum event logs may show 521 (connection refused) or 522 (connection timeout) because a failed TLS handshake at the origin is reported as an origin connection failure. Refer to Event logs for the full status code reference.
• For HTTP/HTTPS applications: clients receive error 525 (SSL handshake failed).

These errors typically appear after creating a Spectrum application or modifying TLS settings.

Cause

The TLS handshake between Cloudflare and your origin server failed. Common causes include:

• Edge TLS Termination is set to Full or Full (Strict), but the origin does not have a valid TLS certificate or does not accept TLS connections on the configured port.
• The Spectrum application origin points to another Cloudflare-proxied hostname (for example, origin.example.com.cdn.cloudflare.net). This creates a double-proxy chain that is not supported for TCP application types and can cause TLS handshake failures.
• TLS version or cipher mismatch between Cloudflare's edge and the origin server.

Solution

1. Verify that your origin server has a valid TLS certificate and is configured to accept TLS connections on the origin port.
2. If using Full (Strict), ensure the origin certificate is issued by a publicly trusted CA or a Cloudflare Origin CA certificate.
3. Confirm that the Spectrum application origin is not pointing to another Cloudflare-proxied hostname. Use a direct origin IP address or a DNS name that resolves directly to your origin server (not through Cloudflare's proxy).
4. If the origin only supports specific TLS versions, note that Spectrum supports TLS 1.1, 1.2, and 1.3 when Edge TLS Termination is turned on.

Common Spectrum event log status codes

Spectrum uses its own set of connection status codes that are distinct from HTTP status codes used by Cloudflare's CDN layer. Some codes share numbers (for example, 444, 499) but have different meanings.

For the full status code table, refer to Event logs.

Common patterns

The following table lists frequently observed Spectrum status code patterns and their likely causes:

Pattern	Likely cause	Recommended action
High volume of 444 (Origin sent RST)	Origin server is actively resetting connections. May indicate origin overload, misconfigured firewall, or application crash.	Check origin server health, firewall rules, and application logs.
High volume of 445 (Origin timeout)	Established connections to origin are timing out. May indicate origin is slow to respond or network path issues.	Check origin server performance and network connectivity between Cloudflare and origin.
High volume of 497 (Client timeout)	Client connections are timing out. May indicate network issues between clients and Cloudflare edge, or clients with very long idle connections.	Review client network conditions and consider adjusting idle timeout expectations.
High volume of 498 (Client broken pipe)	Client connections are dropping mid-session. May indicate unstable client networks (for example, mobile users).	Often expected for mobile or unreliable networks. Monitor for trends.
High volume of 499 (Client sent RST)	Clients are actively closing connections. May indicate client-side timeouts or application-level disconnects.	Review client application timeout settings.
521 (Origin refused connection)	Origin is not accepting connections on the configured port.	Verify origin server is running and listening on the correct port. Check origin firewall.
522 (Origin connection timeout)	Cannot establish a TCP connection to origin.	Verify origin IP address, port, and that origin is reachable from Cloudflare.

Note

Network Analytics data for Spectrum does not reflect the outcomes of IP Access Rules. To verify whether traffic was allowed or blocked based on IP Access Rules, consult the Spectrum event logs.