diff --git a/.github/CODEOWNERS b/.github/CODEOWNERS index feae5b36e4dd9b4..e31470d86dd4c1e 100644 --- a/.github/CODEOWNERS +++ b/.github/CODEOWNERS @@ -69,6 +69,7 @@ package.json @cloudflare/content-engineering /src/content/docs/cloudflare-one/access-controls/ @kennyj42 @ranbel @cloudflare/pcx-technical-writing /src/content/docs/cloudflare-one/team-and-resources/devices/ @ranbel @cloudflare/pcx-technical-writing /src/content/docs/cloudflare-one/networks/connectors/cloudflare-tunnel/ @nikitacano @ranbel @cloudflare/pcx-technical-writing +/src/content/docs/tunnel/ @nikitacano @ranbel @cloudflare/pcx-technical-writing /src/content/docs/cloudflare-one/cloud-and-saas-findings/ @cloudflare/pcx-technical-writing /src/content/docs/cloudflare-one/traffic-policies/ @cloudflare/pcx-technical-writing /src/content/docs/cloudflare-one/remote-browser-isolation/ @deadlypants1973 @cloudflare/pcx-technical-writing diff --git a/.github/labeler.yml b/.github/labeler.yml index f69306930b744d6..47399fda172dab1 100644 --- a/.github/labeler.yml +++ b/.github/labeler.yml @@ -78,6 +78,10 @@ product:cloudflare-one: - changed-files: - any-glob-to-any-file: - src/content/docs/cloudflare-one/** +product:tunnel: + - changed-files: + - any-glob-to-any-file: + - src/content/docs/tunnel/** product:constellation: - changed-files: - any-glob-to-any-file: diff --git a/public/__redirects b/public/__redirects index 759b6b56687dfd8..d2e507e1d210a3a 100644 --- a/public/__redirects +++ b/public/__redirects @@ -2374,6 +2374,8 @@ /cloudflare-one/email-security/settings/trusted-domains/ /cloudflare-one/email-security/settings/detection-settings/trusted-domains/ 301 /cloudflare-one/email-security/monitoring/search-email/ /cloudflare-one/email-security/investigation/search-email/ 301 + + # ============================================================================ # DYNAMIC REDIRECTS # ============================================================================ @@ -2579,3 +2581,30 @@ # Network Flow (formerly Magic Network Monitoring) /magic-network-monitoring/* /network-flow/:splat 301 + +# Cloudflare Tunnel flat structure redirects +/tunnel/get-started/create-remote-tunnel/ /tunnel/setup/ 301 +/tunnel/get-started/create-remote-tunnel-api/ /tunnel/setup/ 301 +/tunnel/get-started/ /tunnel/setup/ 301 +/tunnel/configure-tunnels/tunnel-with-firewall/ /tunnel/configuration/#firewall-rules 301 +/tunnel/configure-tunnels/tunnel-availability/ /tunnel/configuration/#replicas-and-high-availability 301 +/tunnel/configure-tunnels/tunnel-permissions/ /tunnel/configuration/#tunnel-tokens 301 +/tunnel/configure-tunnels/cloudflared-parameters/ /tunnel/configuration/#run-parameters 301 +/tunnel/configure-tunnels/* /tunnel/configuration/ 301 +/tunnel/routing/dns/ /tunnel/routing/#dns-records 301 +/tunnel/routing/load-balancers/ /tunnel/routing/#load-balancing 301 +/tunnel/routing/protocols/ /tunnel/routing/#supported-protocols 301 +/tunnel/integrations/workers-vpc/ /tunnel/integrations/#workers-vpc 301 +/tunnel/integrations/load-balancing/ /tunnel/integrations/#load-balancing 301 +/tunnel/integrations/access/ /tunnel/integrations/#cloudflare-access 301 +/tunnel/integrations/spectrum/ /tunnel/integrations/#spectrum 301 +/tunnel/monitor-tunnels/logs/ /tunnel/monitoring/#logs 301 +/tunnel/monitor-tunnels/metrics/ /tunnel/monitoring/#metrics 301 +/tunnel/monitor-tunnels/notifications/ /tunnel/monitoring/#tunnel-health 301 +/tunnel/monitor-tunnels/* /tunnel/monitoring/ 301 +/tunnel/troubleshoot/common-errors/ /tunnel/troubleshooting/#common-errors 301 +/tunnel/troubleshoot/diag-logs/ /tunnel/monitoring/#diagnostic-logs 301 +/tunnel/troubleshoot/connectivity-prechecks/ /tunnel/troubleshooting/#connectivity-pre-checks 301 +/tunnel/troubleshoot/* /tunnel/troubleshooting/ 301 +/tunnel/downloads/license/ https://github.com/cloudflare/cloudflared/blob/master/LICENSE 301 +/tunnel/downloads/copyrights/ https://github.com/cloudflare/cloudflared 301 diff --git a/src/content/changelog/gateway/2025-09-11-dns-filtering-for-private-network-onramps.mdx b/src/content/changelog/gateway/2025-09-11-dns-filtering-for-private-network-onramps.mdx index 8a2ec7ec387349c..649be1524a95b48 100644 --- a/src/content/changelog/gateway/2025-09-11-dns-filtering-for-private-network-onramps.mdx +++ b/src/content/changelog/gateway/2025-09-11-dns-filtering-for-private-network-onramps.mdx @@ -4,7 +4,7 @@ description: Magic WAN and WARP Connector traffic can now privately route DNS qu products: - gateway - cloudflare-wan - - cloudflare-tunnel + - tunnel date: "2025-09-11" --- @@ -13,4 +13,3 @@ date: "2025-09-11" Routing DNS traffic to the Gateway resolver allows DNS resolution and filtering for traffic coming from private networks while preserving source internal IP visibility. This ensures Magic WAN users have full integration with our Cloudflare One features, including [Internal DNS](/cloudflare-one/traffic-policies/resolver-policies/#internal-dns) and [hostname-based policies](/cloudflare-one/traffic-policies/egress-policies/#selector-prerequisites). To configure DNS filtering, change your Magic WAN or WARP Connector DNS settings to use Cloudflare's shared resolver IPs, `172.64.36.1` and `172.64.36.2`. Once you configure DNS resolution and filtering, you can use _Source Internal IP_ as a traffic selector in your [resolver policies](/cloudflare-one/traffic-policies/resolver-policies/) for routing private DNS traffic to your [Internal DNS](/dns/internal-dns/). - diff --git a/src/content/changelog/cloudflare-tunnel/2024-12-19-diagnostic-logs.mdx b/src/content/changelog/tunnel/2024-12-19-diagnostic-logs.mdx similarity index 90% rename from src/content/changelog/cloudflare-tunnel/2024-12-19-diagnostic-logs.mdx rename to src/content/changelog/tunnel/2024-12-19-diagnostic-logs.mdx index 267fccac7ca1bb0..3eea4fca6905f0d 100644 --- a/src/content/changelog/cloudflare-tunnel/2024-12-19-diagnostic-logs.mdx +++ b/src/content/changelog/tunnel/2024-12-19-diagnostic-logs.mdx @@ -10,6 +10,4 @@ The latest `cloudflared` build [2024.12.2](https://github.com/cloudflare/cloudfl A diagnostic report collects data from a single instance of `cloudflared` running on the local machine and outputs it to a `cloudflared-diag` file. - - For more information, refer to [Diagnostic logs](/cloudflare-one/networks/connectors/cloudflare-tunnel/troubleshoot-tunnels/diag-logs/). diff --git a/src/content/changelog/cloudflare-tunnel/2025-07-15-udp-improvements.mdx b/src/content/changelog/tunnel/2025-07-15-udp-improvements.mdx similarity index 100% rename from src/content/changelog/cloudflare-tunnel/2025-07-15-udp-improvements.mdx rename to src/content/changelog/tunnel/2025-07-15-udp-improvements.mdx diff --git a/src/content/changelog/cloudflare-tunnel/2025-09-02-tunnel-networks-list-endpoints-new-default.mdx b/src/content/changelog/tunnel/2025-09-02-tunnel-networks-list-endpoints-new-default.mdx similarity index 100% rename from src/content/changelog/cloudflare-tunnel/2025-09-02-tunnel-networks-list-endpoints-new-default.mdx rename to src/content/changelog/tunnel/2025-09-02-tunnel-networks-list-endpoints-new-default.mdx diff --git a/src/content/changelog/cloudflare-tunnel/2025-09-18-tunnel-hostname-routing.mdx b/src/content/changelog/tunnel/2025-09-18-tunnel-hostname-routing.mdx similarity index 100% rename from src/content/changelog/cloudflare-tunnel/2025-09-18-tunnel-hostname-routing.mdx rename to src/content/changelog/tunnel/2025-09-18-tunnel-hostname-routing.mdx diff --git a/src/content/changelog/cloudflare-tunnel/2025-11-11-cloudflared-proxy-dns.mdx b/src/content/changelog/tunnel/2025-11-11-cloudflared-proxy-dns.mdx similarity index 97% rename from src/content/changelog/cloudflare-tunnel/2025-11-11-cloudflared-proxy-dns.mdx rename to src/content/changelog/tunnel/2025-11-11-cloudflared-proxy-dns.mdx index 4bf574c93c3f0b9..ed55552c54b68ae 100644 --- a/src/content/changelog/cloudflare-tunnel/2025-11-11-cloudflared-proxy-dns.mdx +++ b/src/content/changelog/tunnel/2025-11-11-cloudflared-proxy-dns.mdx @@ -2,7 +2,7 @@ title: cloudflared proxy-dns command will be removed starting February 2, 2026 description: To address a vulnerability in an underlying library, the `cloudflared proxy-dns` command will be removed from new `cloudflared` releases. Users are advised to migrate to the Cloudflare WARP client or WARP Connector. products: - - cloudflare-tunnel + - tunnel date: 2025-11-11 --- @@ -26,4 +26,4 @@ The preferred method for enabling DNS-over-HTTPS on user devices is the [Cloudfl For scenarios where installing a client on every device is not possible (such as servers, routers, or IoT devices), we recommend using the [WARP Connector](/cloudflare-one/networks/connectors/cloudflare-tunnel/private-net/warp-connector/). -Instead of running `cloudflared proxy-dns` on a machine, you can install the WARP Connector on a single Linux host within your private network. This connector will act as a gateway, securely routing all DNS and network traffic from your [entire subnet](/cloudflare-one/networks/connectors/cloudflare-tunnel/private-net/warp-connector/site-to-internet/) to Cloudflare for [filtering and logging](/cloudflare-one/traffic-policies/). \ No newline at end of file +Instead of running `cloudflared proxy-dns` on a machine, you can install the WARP Connector on a single Linux host within your private network. This connector will act as a gateway, securely routing all DNS and network traffic from your [entire subnet](/cloudflare-one/networks/connectors/cloudflare-tunnel/private-net/warp-connector/site-to-internet/) to Cloudflare for [filtering and logging](/cloudflare-one/traffic-policies/). diff --git a/src/content/changelog/cloudflare-tunnel/2026-01-15-warp-connector-ping-support.mdx b/src/content/changelog/tunnel/2026-01-15-warp-connector-ping-support.mdx similarity index 100% rename from src/content/changelog/cloudflare-tunnel/2026-01-15-warp-connector-ping-support.mdx rename to src/content/changelog/tunnel/2026-01-15-warp-connector-ping-support.mdx diff --git a/src/content/changelog/cloudflare-tunnel/2026-02-20-tunnel-core-dashboard.mdx b/src/content/changelog/tunnel/2026-02-20-tunnel-core-dashboard.mdx similarity index 100% rename from src/content/changelog/cloudflare-tunnel/2026-02-20-tunnel-core-dashboard.mdx rename to src/content/changelog/tunnel/2026-02-20-tunnel-core-dashboard.mdx diff --git a/src/content/changelog/zero-trust-warp/2024-06-16-cloudflare-one.mdx b/src/content/changelog/zero-trust-warp/2024-06-16-cloudflare-one.mdx index abbd4517ade4441..37bfdc123ec7a39 100644 --- a/src/content/changelog/zero-trust-warp/2024-06-16-cloudflare-one.mdx +++ b/src/content/changelog/zero-trust-warp/2024-06-16-cloudflare-one.mdx @@ -5,7 +5,7 @@ products: - access - browser-isolation - casb - - cloudflare-tunnel + - tunnel - dex - dlp - email-security-cf1 diff --git a/src/content/dash-routes/core-manually-defined.json b/src/content/dash-routes/core-manually-defined.json index fe51488c7066f66..6516b8124d72bdd 100644 --- a/src/content/dash-routes/core-manually-defined.json +++ b/src/content/dash-routes/core-manually-defined.json @@ -1 +1,7 @@ -[] +[ + { + "deeplink": "/?to=/:account/tunnels", + "name": "Tunnels", + "parent": ["Networking"] + } +] diff --git a/src/content/directory/cloudflare-tunnel-sase.yaml b/src/content/directory/cloudflare-tunnel-sase.yaml new file mode 100644 index 000000000000000..36de8244eb1ee4f --- /dev/null +++ b/src/content/directory/cloudflare-tunnel-sase.yaml @@ -0,0 +1,10 @@ +id: tUn3lSASE +name: Cloudflare Tunnel for SASE + +entry: + title: Cloudflare Tunnel for SASE + group: Cloudflare One + url: /cloudflare-one/networks/connectors/cloudflare-tunnel/ + +meta: + description: Connect private networks and resources to Cloudflare One diff --git a/src/content/directory/cloudflare-tunnel.yaml b/src/content/directory/cloudflare-tunnel.yaml deleted file mode 100644 index d037860d25bcc48..000000000000000 --- a/src/content/directory/cloudflare-tunnel.yaml +++ /dev/null @@ -1,10 +0,0 @@ -id: rUdNKP -name: Cloudflare Tunnel - -entry: - title: Cloudflare Tunnel - group: Cloudflare One - url: /cloudflare-one/networks/connectors/cloudflare-tunnel/ - -meta: - description: Securely connect resources to Cloudflare without a publicly routable IP address diff --git a/src/content/directory/tunnel.yaml b/src/content/directory/tunnel.yaml new file mode 100644 index 000000000000000..1eda0d294295e41 --- /dev/null +++ b/src/content/directory/tunnel.yaml @@ -0,0 +1,14 @@ +id: rUdNKP +name: Cloudflare Tunnel + +entry: + title: Cloudflare Tunnel + group: Core platform + additional_groups: + - Network security + - Application security + - Developer platform + url: /tunnel/ + +meta: + description: Connect your origin servers, APIs, and services to Cloudflare without a publicly routable IP address diff --git a/src/content/docs/cloudflare-one/changelog/tunnel.mdx b/src/content/docs/cloudflare-one/changelog/tunnel.mdx index 264cae9e738edfb..360096688b43728 100644 --- a/src/content/docs/cloudflare-one/changelog/tunnel.mdx +++ b/src/content/docs/cloudflare-one/changelog/tunnel.mdx @@ -9,10 +9,10 @@ description: Review recent changes to Cloudflare Tunnel. import { ProductChangelog, Render } from "~/components"; -{/* S1 - cf2-->S1 - end - C -- "Connections x 4
"--> cf1 - C --> cf1 - C --> cf1 - C --> cf1 - C -- Connections x 4--> cf2 - C --> cf2 - C --> cf2 - C --> cf2 -``` + By design, replicas do not offer any level of traffic steering (random, hash, or round-robin). Instead, when a request arrives to Cloudflare, it will be forwarded to the replica that is geographically closest. If that distance calculation is unsuccessful or the connection fails, we will retry others, but there is no guarantee about which connection is chosen. @@ -51,26 +33,26 @@ For setup instructions, refer to [Deploy cloudflared replicas](/cloudflare-one/n ```mermaid graph LR - accTitle: Load balancing traffic to applications behind Cloudflare Tunnel + accTitle: Load balancing traffic to applications behind Cloudflare Tunnel A[Internet] --> C{Cloudflare
Load Balancer} B[WARP clients] --> C - M[Cloudflare WAN] --> C + M[Cloudflare WAN] --> C C -- Tunnel 1 --> cf1 C -- Tunnel 2 --> cf2 - subgraph F[Data center 2] - cf2[cloudflared
server] - S3[App server] + subgraph F[Data center 2] + cf2[cloudflared
server] + S3[App server] S4[App server] - cf2-->S3 - cf2-->S4 + cf2-->S3 + cf2-->S4 end - subgraph E[Data center 1] - cf1[cloudflared
server] + subgraph E[Data center 1] + cf1[cloudflared
server] S1[App server] S2[App server] - cf1-->S1 - cf1-->S2 + cf1-->S1 + cf1-->S2 end ``` diff --git a/src/content/docs/cloudflare-one/networks/connectors/cloudflare-tunnel/configure-tunnels/tunnel-availability/system-requirements.mdx b/src/content/docs/cloudflare-one/networks/connectors/cloudflare-tunnel/configure-tunnels/tunnel-availability/system-requirements.mdx index dc5d5a91016a2b4..0dd296a4b6ac162 100644 --- a/src/content/docs/cloudflare-one/networks/connectors/cloudflare-tunnel/configure-tunnels/tunnel-availability/system-requirements.mdx +++ b/src/content/docs/cloudflare-one/networks/connectors/cloudflare-tunnel/configure-tunnels/tunnel-availability/system-requirements.mdx @@ -26,36 +26,7 @@ When `cloudflared` receives a request from a WARP device, it uses the ports on t - `cloudflared` should be deployed on a dedicated host machine. This model is typically appropriate, but there may be serverless or clustered workflows where a dedicated host is not possible. - The host machine should allocate 50,000 ports to be available for use by the `cloudflared` service. The remaining ports are reserved for system administrative processes. - - -To increase the number of ports available to `cloudflared` on Linux: - -If your machine has a `/etc/sysctl.d/` directory: - -```sh -echo 'net.ipv4.ip_local_port_range = 11000 60999' | sudo tee -a /etc/sysctl.d/99-cloudflared.conf -sudo sysctl -p /etc/sysctl.d/99-cloudflared.conf -``` - -Otherwise: - -```sh -echo 'net.ipv4.ip_local_port_range = 11000 60999' | sudo tee -a /etc/sysctl.conf -sudo sysctl -p /etc/sysctl.conf -``` - - - -To increase the number of ports available to `cloudflared` on Windows, set the [dynamic port range](https://learn.microsoft.com/en-us/troubleshoot/windows-client/networking/tcp-ip-port-exhaustion-troubleshooting) for TCP and UDP: - -```txt -netsh int ipv4 set dynamicport tcp start=11000 num=50000 -netsh int ipv4 set dynamicport udp start=11000 num=50000 -netsh int ipv6 set dynamicport tcp start=11000 num=50000 -netsh int ipv6 set dynamicport udp start=11000 num=50000 -``` - - + ### Private DNS @@ -63,25 +34,7 @@ DNS queries utilize [more system resources](#estimated-throughput) compared to T ### ulimits -On Linux and macOS, `ulimit` settings determine the system resources available to a logged-in user. We recommend configuring the following ulimits on the `cloudflared` server: - -| ulimit | Description | Value | -| ------ | ------------------------------------------------ | -------- | -| `-n` | Maximum number of open files or file descriptors | ≥ 70,000 | - -To view your current ulimits, open a terminal and run: - -```sh -ulimit -a -``` - -To set the open files `ulimit`: - -```sh -ulimit -n 70000 -``` - -The command above sets the open files limit only for the current terminal session and will not persist after a reboot or new login. To apply this limit permanently, configure it using the persistent method appropriate for your operating system. + ## Estimated throughput diff --git a/src/content/docs/cloudflare-one/networks/connectors/cloudflare-tunnel/configure-tunnels/tunnel-with-firewall.mdx b/src/content/docs/cloudflare-one/networks/connectors/cloudflare-tunnel/configure-tunnels/tunnel-with-firewall.mdx index c951531a484ff01..06c86f93630ec23 100644 --- a/src/content/docs/cloudflare-one/networks/connectors/cloudflare-tunnel/configure-tunnels/tunnel-with-firewall.mdx +++ b/src/content/docs/cloudflare-one/networks/connectors/cloudflare-tunnel/configure-tunnels/tunnel-with-firewall.mdx @@ -7,6 +7,8 @@ sidebar: order: 3 --- +import { Render } from "~/components"; + You can implement a positive security model with Cloudflare Tunnel by blocking all ingress traffic and allowing only egress traffic from `cloudflared`. Only the services specified in your tunnel configuration will be exposed to the outside world. ## Ports @@ -24,65 +26,18 @@ Ensure port `7844` is allowed for both TCP and UDP protocols (for `http2` and `q `cloudflared` connects to Cloudflare's global network on port `7844`. To use Cloudflare Tunnel, your firewall must allow outbound connections to the following destinations on port `7844` (via UDP if using the `quic` protocol or TCP if using the `http2` protocol). -#### `region1.v2.argotunnel.com` - -| IPv4 | IPv6 | Port | Protocols | -| ----------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ---- | ------------------------ | -| `198.41.192.167` `198.41.192.67` `198.41.192.57` `198.41.192.107` `198.41.192.27` `198.41.192.7` `198.41.192.227` `198.41.192.47` `198.41.192.37` `198.41.192.77` | `2606:4700:a0::1` `2606:4700:a0::2` `2606:4700:a0::3` `2606:4700:a0::4` `2606:4700:a0::5` `2606:4700:a0::6` `2606:4700:a0::7` `2606:4700:a0::8` `2606:4700:a0::9` `2606:4700:a0::10` | 7844 | TCP/UDP (`http2`/`quic`) | - -#### `region2.v2.argotunnel.com` - -| IPv4 | IPv6 | Port | Protocols | -| ------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ---- | ------------------------ | -| `198.41.200.13` `198.41.200.193` `198.41.200.33` `198.41.200.233` `198.41.200.53` `198.41.200.63` `198.41.200.113` `198.41.200.73` `198.41.200.43` `198.41.200.23` | `2606:4700:a8::1` `2606:4700:a8::2` `2606:4700:a8::3` `2606:4700:a8::4` `2606:4700:a8::5` `2606:4700:a8::6` `2606:4700:a8::7` `2606:4700:a8::8` `2606:4700:a8::9` `2606:4700:a8::10` | 7844 | TCP/UDP (`http2`/`quic`) | - -#### `_v2-origintunneld._tcp.argotunnel.com` - -| IPv4 | IPv6 | Port | Protocols | -| -------------- | -------------- | ---- | ------------- | -| Not applicable | Not applicable | 7844 | TCP (`http2`) | - -This rule is only required for firewalls that enforce SNI. - -#### `cftunnel.com` - -| IPv4 | IPv6 | Port | Protocols | -| -------------- | -------------- | ---- | ------------------------ | -| Not applicable | Not applicable | 7844 | TCP/UDP (`http2`/`quic`) | - -This rule is only required for firewalls that enforce SNI. - -#### `h2.cftunnel.com` + -| IPv4 | IPv6 | Port | Protocols | -| -------------- | -------------- | ---- | ------------- | -| Not applicable | Not applicable | 7844 | TCP (`http2`) | - -This rule is only required for firewalls that enforce SNI. - -#### `quic.cftunnel.com` - -| IPv4 | IPv6 | Port | Protocols | -| -------------- | -------------- | ---- | ------------ | -| Not applicable | Not applicable | 7844 | UDP (`quic`) | - -This rule is only required for firewalls that enforce SNI. +#### SNI-enforcing firewalls + ### Region US -When using the [US region](/cloudflare-one/networks/connectors/cloudflare-tunnel/configure-tunnels/cloudflared-parameters/run-parameters/#region), ensure your firewall allows outbound connections to these US-region destinations on port `7844` (TCP/UDP) for tunnel operation. - -#### `us-region1.v2.argotunnel.com` - -| IPv4 | IPv6 | Port | Protocol | -| ------------------------------------------------------------------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ---- | ------------------------ | -| `198.41.218.1` `198.41.218.2` `198.41.218.3` `198.41.218.4` `198.41.218.5` `198.41.218.6` `198.41.218.7` `198.41.218.8` `198.41.218.9` `198.41.218.10` | `2606:4700:a1::1` `2606:4700:a1::2` `2606:4700:a1::3` `2606:4700:a1::4` `2606:4700:a1::5` `2606:4700:a1::6` `2606:4700:a1::7` `2606:4700:a1::8` `2606:4700:a1::9` `2606:4700:a1::10` | 7844 | TCP/UDP (`http2`/`quic`) | - -#### `us-region2.v2.argotunnel.com` - -| IPv4 | IPv6 | Port | Protocol | -| ------------------------------------------------------------------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ---- | ------------------------ | -| `198.41.219.1` `198.41.219.2` `198.41.219.3` `198.41.219.4` `198.41.219.5` `198.41.219.6` `198.41.219.7` `198.41.219.8` `198.41.219.9` `198.41.219.10` | `2606:4700:a9::1` `2606:4700:a9::2` `2606:4700:a9::3` `2606:4700:a9::4` `2606:4700:a9::5` `2606:4700:a9::6` `2606:4700:a9::7` `2606:4700:a9::8` `2606:4700:a9::9` `2606:4700:a9::10` | 7844 | TCP/UDP (`http2`/`quic`) | + ### Optional diff --git a/src/content/docs/cloudflare-one/networks/connectors/cloudflare-tunnel/do-more-with-tunnels/index.mdx b/src/content/docs/cloudflare-one/networks/connectors/cloudflare-tunnel/do-more-with-tunnels/index.mdx index 1c02f368a5e678f..966ebd975b574c4 100644 --- a/src/content/docs/cloudflare-one/networks/connectors/cloudflare-tunnel/do-more-with-tunnels/index.mdx +++ b/src/content/docs/cloudflare-one/networks/connectors/cloudflare-tunnel/do-more-with-tunnels/index.mdx @@ -1,11 +1,14 @@ --- pcx_content_type: navigation -title: Do more with Tunnel +title: Other tunnel types sidebar: order: 11 - --- -import { DirectoryListing } from "~/components" +import { DirectoryListing } from "~/components"; + +Cloudflare recommends creating a [remotely-managed tunnel](/cloudflare-one/networks/connectors/cloudflare-tunnel/get-started/) for most use cases. Remotely-managed tunnels store their configuration on Cloudflare, which allows you to manage the tunnel from any machine using the dashboard, API, or Terraform. + +The following pages cover alternative tunnel workflows that are intended for specific scenarios such as local development, testing, or legacy configurations. diff --git a/src/content/docs/cloudflare-one/networks/connectors/cloudflare-tunnel/do-more-with-tunnels/local-management/index.mdx b/src/content/docs/cloudflare-one/networks/connectors/cloudflare-tunnel/do-more-with-tunnels/local-management/index.mdx index 07490b615f393ee..de6e702d15d28ae 100644 --- a/src/content/docs/cloudflare-one/networks/connectors/cloudflare-tunnel/do-more-with-tunnels/local-management/index.mdx +++ b/src/content/docs/cloudflare-one/networks/connectors/cloudflare-tunnel/do-more-with-tunnels/local-management/index.mdx @@ -3,11 +3,9 @@ pcx_content_type: navigation title: Locally-managed tunnels sidebar: order: 2 - --- -import { DirectoryListing } from "~/components" - +import { DirectoryListing } from "~/components"; A locally-managed tunnel is a Cloudflare Tunnel created by running `cloudflared tunnel create ` on the command line. Tunnel configuration is stored in your local [cloudflared directory](#default-cloudflared-directory). diff --git a/src/content/docs/cloudflare-one/networks/connectors/cloudflare-tunnel/do-more-with-tunnels/trycloudflare.mdx b/src/content/docs/cloudflare-one/networks/connectors/cloudflare-tunnel/do-more-with-tunnels/trycloudflare.mdx index e5dda0a69985d5f..5d1ccf36a5cc612 100644 --- a/src/content/docs/cloudflare-one/networks/connectors/cloudflare-tunnel/do-more-with-tunnels/trycloudflare.mdx +++ b/src/content/docs/cloudflare-one/networks/connectors/cloudflare-tunnel/do-more-with-tunnels/trycloudflare.mdx @@ -5,6 +5,10 @@ sidebar: order: 5 --- +:::note +Quick Tunnels are intended for testing and development only. For production use, [create a remotely-managed tunnel](/cloudflare-one/networks/connectors/cloudflare-tunnel/get-started/). +::: + Developers can use the TryCloudflare tool to experiment with Cloudflare Tunnel without adding a site to Cloudflare's DNS. TryCloudflare will launch a process that generates a random subdomain on `trycloudflare.com`. Requests to that subdomain will be proxied through the Cloudflare network to your web server running on localhost. ## Use TryCloudflare diff --git a/src/content/docs/cloudflare-one/networks/connectors/cloudflare-tunnel/index.mdx b/src/content/docs/cloudflare-one/networks/connectors/cloudflare-tunnel/index.mdx index 780848b9d33a60c..364a0fe3be4c025 100644 --- a/src/content/docs/cloudflare-one/networks/connectors/cloudflare-tunnel/index.mdx +++ b/src/content/docs/cloudflare-one/networks/connectors/cloudflare-tunnel/index.mdx @@ -7,7 +7,7 @@ sidebar: import { Render, Stream } from "~/components"; -Cloudflare Tunnel provides you with a secure way to connect your resources to Cloudflare without a publicly routable IP address. With Tunnel, you do not send traffic to an external IP — instead, a lightweight daemon in your infrastructure (`cloudflared`) creates [outbound-only connections](/cloudflare-one/networks/connectors/cloudflare-tunnel/#outbound-only-connection) to Cloudflare's global network. Cloudflare Tunnel can connect HTTP web servers, [SSH servers](/cloudflare-one/networks/connectors/cloudflare-tunnel/use-cases/ssh/), [remote desktops](/cloudflare-one/networks/connectors/cloudflare-tunnel/use-cases/rdp/), and other protocols safely to Cloudflare. This way, your origins can serve traffic through Cloudflare without being vulnerable to attacks that bypass Cloudflare. +Cloudflare Tunnel provides you with a secure way to connect your resources to Cloudflare without a publicly routable IP address. With Tunnel, you do not send traffic to an external IP — instead, a lightweight daemon in your infrastructure (`cloudflared`) creates [outbound-only connections](#outbound-only-connections) to Cloudflare's global network. Cloudflare Tunnel can connect HTTP web servers, [SSH servers](/cloudflare-one/networks/connectors/cloudflare-tunnel/use-cases/ssh/), [remote desktops](/cloudflare-one/networks/connectors/cloudflare-tunnel/use-cases/rdp/), and other protocols safely to Cloudflare. This way, your origins can serve traffic through Cloudflare without being vulnerable to attacks that bypass Cloudflare. Refer to our [reference architecture](/reference-architecture/architectures/sase/) for details on how to implement Cloudflare Tunnel into your existing infrastructure. @@ -19,11 +19,11 @@ Refer to our [reference architecture](/reference-architecture/architectures/sase ## How it works -Cloudflared establishes [outbound connections](/cloudflare-one/networks/connectors/cloudflare-tunnel/#outbound-only-connection) (tunnels) between your resources and Cloudflare's global network. Tunnels are persistent objects that route traffic to DNS records. Within the same tunnel, you can run as many 'cloudflared' processes (connectors) as needed. These processes will establish connections to Cloudflare and send traffic to the nearest Cloudflare data center. +`cloudflared` establishes [outbound connections](#outbound-only-connections) (tunnels) between your resources and Cloudflare's global network. Tunnels are persistent objects that route traffic to DNS records. Within the same tunnel, you can run as many 'cloudflared' processes (connectors) as needed. These processes will establish connections to Cloudflare and send traffic to the nearest Cloudflare data center. ![How an HTTP request reaches a private application connected with Cloudflare Tunnel](~/assets/images/cloudflare-one/connections/connect-apps/handshake.jpg) -## Outbound-only connection +### Outbound-only connections Cloudflare Tunnel uses an outbound-only connection model to enable bidirectional communication. When you install and run `cloudflared`, `cloudflared` initiates an outbound connection through your firewall from the origin to the Cloudflare global network. @@ -32,6 +32,5 @@ Once the connection is established, traffic flows in both directions over the tu ## Next steps - Create a tunnel using the [Cloudflare dashboard](/cloudflare-one/networks/connectors/cloudflare-tunnel/get-started/create-remote-tunnel/) or [API](/cloudflare-one/networks/connectors/cloudflare-tunnel/get-started/create-remote-tunnel-api/). -- Learn more about [`cloudflared`](/cloudflare-one/networks/connectors/cloudflare-tunnel/downloads/), the server-side daemon that connects your infrastructure to Cloudflare. +- [Download `cloudflared`](/cloudflare-one/networks/connectors/cloudflare-tunnel/downloads/), the server-side daemon that connects your infrastructure to Cloudflare. - Review useful [Tunnel terms](/cloudflare-one/networks/connectors/cloudflare-tunnel/get-started/tunnel-useful-terms/) to familiarize yourself with the concepts used in Tunnel documentation. -- [Troubleshoot](/cloudflare-one/networks/connectors/cloudflare-tunnel/troubleshoot-tunnels/) your Tunnel by reviewing available logs and common errors. diff --git a/src/content/docs/cloudflare-one/networks/connectors/cloudflare-tunnel/monitor-tunnels/logs.mdx b/src/content/docs/cloudflare-one/networks/connectors/cloudflare-tunnel/monitor-tunnels/logs.mdx index 5915f5ec294e60e..d8e5c5da399c00e 100644 --- a/src/content/docs/cloudflare-one/networks/connectors/cloudflare-tunnel/monitor-tunnels/logs.mdx +++ b/src/content/docs/cloudflare-one/networks/connectors/cloudflare-tunnel/monitor-tunnels/logs.mdx @@ -8,19 +8,21 @@ head: content: Tunnel log streams --- +import { Render } from "~/components"; + Tunnel logs record all activity between a `cloudflared` instance and Cloudflare's global network, as well as all activity between `cloudflared` and your origin server. These logs allow you to investigate connectivity or performance issues with a Cloudflare Tunnel. You can configure your server to store persistent logs, or you can stream real-time logs from any client machine. ## View logs on the server -If you have access to the origin server, you can use the [`--loglevel` flag](/cloudflare-one/networks/connectors/cloudflare-tunnel/configure-tunnels/cloudflared-parameters/run-parameters/#loglevel) to enable logging when you start the tunnel. By default, `cloudflared` prints logs to stdout and does not store logs on the server. You can optionally use the [`--logfile` flag](/cloudflare-one/networks/connectors/cloudflare-tunnel/configure-tunnels/cloudflared-parameters/run-parameters/#logfile) to write your logs to a file. - -To enable logs for a locally-managed tunnel: - -```sh -cloudflared tunnel --loglevel info --logfile cloudflared.log run -``` - -To enable logs for a remotely-managed tunnel, add `--loglevel info` and `--logfile ` to your system service as shown in [Add tunnel run parameters](/cloudflare-one/networks/connectors/cloudflare-tunnel/configure-tunnels/cloudflared-parameters/#update-tunnel-run-parameters). + ## View logs on your local machine @@ -42,40 +44,17 @@ Dashboard log streams are only available for remotely-managed tunnels. To view l The `cloudflared` daemon can stream logs from any tunnel in your account to the local command line. `cloudflared` must be installed on both your local machine and the origin server. -#### View logs - -1. On your local machine, authenticate `cloudflared` to your Cloudflare One account: - - ```sh - cloudflared tunnel login - ``` - -2. Run `cloudflared tail` for a specific tunnel: - - ```sh - cloudflared tail - ``` - - For a more structured view of the JSON message, you can pipe the output to tools like [jq](https://stedolan.github.io/jq/): - - ```sh - cloudflared tail --output=json | jq . - ``` + #### Filter logs -You can filter logs by event type (`--event`), event level (`--level`), or sampling rate (`-sampling`) to reduce the volume of logs streamed from the origin. This helps mitigate the performance impact on the origin, especially when the origin is normally under high load. For example: - -```sh -cloudflared tail --level debug -``` - -| Flag | Description | Allowed values | Default value | -| ------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------- | ------------- | -| `--event` | Filter by the type of event / request. | `cloudflared`, `http`, `tcp`, `udp` | All events | -| `--level` | Return logs at this level and above. Works independently of the [`--loglevel`](/cloudflare-one/networks/connectors/cloudflare-tunnel/configure-tunnels/cloudflared-parameters/run-parameters/#loglevel) setting on the server. | `debug`, `info`, `warn`, `error`, `fatal` | `debug` | -| `--sampling` | Sample a fraction of the total logs. | Number from `0.0` to `1.0` | `1.0` | -| | | | | + #### View logs for a replica diff --git a/src/content/docs/cloudflare-one/networks/connectors/cloudflare-tunnel/monitor-tunnels/metrics.mdx b/src/content/docs/cloudflare-one/networks/connectors/cloudflare-tunnel/monitor-tunnels/metrics.mdx index 9cd270e5729e85c..5299a5800d4f4fa 100644 --- a/src/content/docs/cloudflare-one/networks/connectors/cloudflare-tunnel/monitor-tunnels/metrics.mdx +++ b/src/content/docs/cloudflare-one/networks/connectors/cloudflare-tunnel/monitor-tunnels/metrics.mdx @@ -8,104 +8,40 @@ head: content: Tunnel metrics --- -Tunnel metrics show a Cloudflare Tunnel's throughput and resource usage over time. When you run a tunnel, `cloudflared` will spin up a Prometheus metrics endpoint — an HTTP server that exposes metrics in [Prometheus](https://prometheus.io/docs/introduction/overview/) format. You can use the Prometheus toolkit on a remote machine to scrape metrics data from the `cloudflared` server. +import { Render } from "~/components"; -## Default metrics server address - -In non-containerized environments, `cloudflared` starts the metrics server on `127.0.0.1:/metrics`, where `` is the first available port in the range `20241` to `20245`. In case of all ports being unavailable then the fallback is to bind to a random port. In containerized environments such as Docker and Kubernetes, the default address is `0.0.0.0:/metrics`. + -To determine the default port being used by a `cloudflared` instance, you can check your [Tunnel logs](/cloudflare-one/networks/connectors/cloudflare-tunnel/monitor-tunnels/logs/) around the time when the tunnel started. For example: +## Default metrics server address -```text -2024-12-19T21:17:58Z INF Starting metrics server on 127.0.0.1:20241/metrics -``` + ## Configure the metrics server address -To serve metrics on a custom IP address and port, perform these steps on the `cloudflared` host: - -1. Run the tunnel using the [--metrics](/cloudflare-one/networks/connectors/cloudflare-tunnel/configure-tunnels/cloudflared-parameters/run-parameters/#metrics) flag. Here is an example command for a locally-managed tunnel: - - ```sh - cloudflared tunnel --metrics 127.0.0.1:60123 run my-tunnel - ``` - - To learn how to add the `--metrics` flag to a remotely-managed tunnel, refer to [Configure a remotely-managed tunnel](/cloudflare-one/networks/connectors/cloudflare-tunnel/configure-tunnels/cloudflared-parameters/#update-tunnel-run-parameters). - - :::note - If you plan to fetch metrics from another machine on the local network, replace `127.0.0.1` with the internal IP of the `cloudflared` server (for example, `198.168.x.x`). To serve metrics on all available network interfaces, use `0.0.0.0`. - ::: - -2. Verify that the metrics server is running by going to `http://localhost:60123/metrics`. This will only work if you configured a localhost IP (`127.0.0.1` or `0.0.0.0`). - -You can now export the metrics to Prometheus and Grafana in order to visualize and query the data. Refer to our [tutorial](/cloudflare-one/tutorials/grafana/) for instructions on getting started with these tools. + ## Available metrics ### cloudflared metrics -| Name | Description | Type | Labels | -| --------------------------------------------------- | ---------------------------------------------------------------------------------------------------------- | ------- | ------------------------------------------ | -| `build_info` | Build and version information. | GAUGE | `goversion`, `revision`, `type`, `version` | -| `cloudflared_config_local_config_pushes` | Number of local configuration pushes to Cloudflare. | COUNTER | | -| `cloudflared_config_local_config_pushes_errors` | Number of errors that occurred during local configuration pushes. | COUNTER | | -| `cloudflared_orchestration_config_version` | Configuration version. | GAUGE | | -| `cloudflared_tcp_active_sessions` | Concurrent number of TCP sessions that are being proxied to any origin. | GAUGE | | -| `cloudflared_tcp_total_sessions` | Total number of TCP sessions that have been proxied to any origin. | COUNTER | | -| `cloudflared_tunnel_active_streams` | Total number of active streams. | GAUGE | | -| `cloudflared_tunnel_concurrent_requests_per_tunnel` | Concurrent number of requests proxied through each tunnel. | GAUGE | | -| `cloudflared_tunnel_ha_connections` | Number of active HA connections. | GAUGE | | -| `cloudflared_tunnel_request_errors` | Number of errors proxying to origin. | COUNTER | | -| `cloudflared_tunnel_server_locations` | Where each tunnel is connected to. `1` means current location, `0` means previous locations. | GAUGE | `connection_id`, `edge_location` | -| `cloudflared_tunnel_timer_retries` | Unacknowledged heart beats count. | GAUGE | | -| `cloudflared_tunnel_total_requests` | Number of requests proxied through all tunnels. | COUNTER | | -| `cloudflared_tunnel_tunnel_authenticate_success` | Number of successful tunnel authentication events. | COUNTER | | -| `cloudflared_tunnel_tunnel_register_success` | Number of successful tunnel registrations. | COUNTER | `rpcName` | -| `cloudflared_udp_active_sessions` | Concurrent number of UDP sessions that are being proxied to any origin. | GAUGE | | -| `cloudflared_udp_total_sessions` | Total number of UDP sessions that have been proxied to any origin. | COUNTER | | -| `coredns_panics_total` | Number of panics. | COUNTER | | -| `quic_client_closed_connections` | Number of connections that have been closed. | COUNTER | | -| `quic_client_latest_rtt` | Latest round-trip time (RTT) measured on a connection. | GAUGE | `conn_index` | -| `quic_client_lost_packets` | Number of packets that have been lost from a connection. | COUNTER | `conn_index`, `reason` | -| `quic_client_min_rtt` | Lowest RTT measured on a connection in ms. | GAUGE | `conn_index` | -| `quic_client_packet_too_big_dropped` | Number of packets received from origin that are too big to send to Cloudflare and are dropped as a result. | COUNTER | | -| `quic_client_smoothed_rtt` | Smoothed RTT calculated for a connection in ms. | GAUGE | `conn_index` | -| `quic_client_total_connections` | Number of connections initiated. For all QUIC metrics, client means the side initiating the connection. | COUNTER | | + ### Prometheus metrics -| Name | Description | Type | Labels | -| -------------------------------------------- | -------------------------------------------- | ------- | ------ | -| `promhttp_metric_handler_requests_in_flight` | Current number of scrapes being served. | GAUGE | | -| `promhttp_metric_handler_requests_total` | Total number of scrapes by HTTP status code. | COUNTER | `code` | -| | | | | + ### Go runtime metrics -| Name | Description | Type | Labels | -| ---------------------------------- | ------------------------------------------------------------------ | ------- | --------- | -| `go_gc_duration_seconds` | A summary of the pause duration of garbage collection cycles. | SUMMARY | | -| `go_goroutines` | Number of goroutines that currently exist. | GAUGE | | -| `go_info` | Information about the Go environment. | GAUGE | `version` | -| `go_memstats_alloc_bytes` | Number of bytes allocated and still in use. | GAUGE | | -| `go_memstats_alloc_bytes_total` | Total number of bytes allocated, even if freed. | COUNTER | | -| `go_memstats_buck_hash_sys_bytes` | Number of bytes used by the profiling bucket hash table. | GAUGE | | -| `go_memstats_frees_total` | Total number of frees. | COUNTER | | -| `go_memstats_gc_sys_bytes` | Number of bytes used for garbage collection system metadata. | GAUGE | | -| `go_memstats_heap_alloc_bytes` | Number of heap bytes allocated and still in use. | GAUGE | | -| `go_memstats_heap_idle_bytes` | Number of heap bytes waiting to be used. | GAUGE | | -| `go_memstats_heap_inuse_bytes` | Number of heap bytes that are in use. | GAUGE | | -| `go_memstats_heap_objects` | Number of allocated objects. | GAUGE | | -| `go_memstats_heap_released_bytes` | Number of heap bytes released to OS. | GAUGE | | -| `go_memstats_heap_sys_bytes` | Number of heap bytes obtained from system. | GAUGE | | -| `go_memstats_last_gc_time_seconds` | Number of seconds since 1970 of last garbage collection. | GAUGE | | -| `go_memstats_lookups_total` | Total number of pointer lookups. | COUNTER | | -| `go_memstats_mallocs_total` | Total number of mallocs. | COUNTER | | -| `go_memstats_mcache_inuse_bytes` | Number of bytes in use by mcache structures. | GAUGE | | -| `go_memstats_mcache_sys_bytes` | Number of bytes used for mcache structures obtained from system. | GAUGE | | -| `go_memstats_mspan_inuse_bytes` | Number of bytes in use by mspan structures. | GAUGE | | -| `go_memstats_mspan_sys_bytes` | Number of bytes used for mspan structures obtained from system. | GAUGE | | -| `go_memstats_next_gc_bytes` | Number of heap bytes when next garbage collection will take place. | GAUGE | | -| `go_memstats_other_sys_bytes` | Number of bytes used for other system allocations. | GAUGE | | -| `go_memstats_stack_inuse_bytes` | Number of bytes in use by the stack allocator. | GAUGE | | -| | | | | + diff --git a/src/content/docs/cloudflare-one/networks/connectors/cloudflare-tunnel/routing-to-tunnel/dns.mdx b/src/content/docs/cloudflare-one/networks/connectors/cloudflare-tunnel/routing-to-tunnel/dns.mdx index 6f219052333e4b9..43a98b63631b858 100644 --- a/src/content/docs/cloudflare-one/networks/connectors/cloudflare-tunnel/routing-to-tunnel/dns.mdx +++ b/src/content/docs/cloudflare-one/networks/connectors/cloudflare-tunnel/routing-to-tunnel/dns.mdx @@ -5,55 +5,20 @@ sidebar: order: 2 --- -import { Render, TabItem, Tabs, DashButton } from "~/components"; +import { Render } from "~/components"; -When you create a tunnel, Cloudflare generates a subdomain of `cfargotunnel.com` with the UUID of the created tunnel. You can treat `.cfargotunnel.com` as if it were an origin target in the Cloudflare dashboard. + -Unlike publicly routable IP addresses, `.cfargotunnel.com` will only proxy traffic for a DNS record in the same Cloudflare account. The Tunnel UUID is not secret information; if someone discovers your subdomain UUID, they will not be able to create a DNS record in another account or system to proxy traffic to the address. +## Create a DNS record -## Create a DNS record for the tunnel + - +## Cloudflare settings -To create a new DNS record for your tunnel: - -1. Log in to the [Cloudflare dashboard](https://dash.cloudflare.com/) and go to the **DNS Records** page for your domain. - - -2. Select **Add record**. -3. Input the following information: - - **Type**: _CNAME_ - - **Name**: Subdomain of your application - - **Target**: `.cfargotunnel.com` -4. Select **Save**. - -![Example of fields completed to create a new CNAME record.](~/assets/images/cloudflare-one/connections/connect-apps/dns/dns-record.png) - - - - - -You can create a new DNS record directly from `cloudflared`: - -```sh -cloudflared tunnel route dns www.app.com -``` - -This command create a `CNAME` record that points to the tunnel subdomain, but will not proxy traffic if the tunnel is not currently running. - -:::note - -To create DNS records using `cloudflared`, the [`cert.pem`](/cloudflare-one/networks/connectors/cloudflare-tunnel/do-more-with-tunnels/local-management/local-tunnel-terms/#certpem) file must be installed on your system. -::: - - - - - -The DNS record is distinct from the state of the tunnel. You can create DNS records that point to a tunnel that is not currently running. If the tunnel stops running, the DNS record will not be deleted. If you point the DNS record to a tunnel not currently running, visitors will see a `1016` error message. - -Additionally, you can create multiple DNS records that point to the same tunnel subdomain. If you are routing traffic from multiple hostnames to multiple services, you will need to create a `CNAME` entry for each hostname. The CNAME entries will share the same target. - -## Optional Cloudflare settings - -The application will default to the Cloudflare settings of the hostname in your account that includes the Cloudflare Tunnel DNS record, including [cache rules](/cache/how-to/cache-rules/) and [firewall policies](/firewall/). You can changes these settings for your hostname in Cloudflare's dashboard. + \ No newline at end of file diff --git a/src/content/docs/cloudflare-one/networks/connectors/cloudflare-tunnel/routing-to-tunnel/protocols.mdx b/src/content/docs/cloudflare-one/networks/connectors/cloudflare-tunnel/routing-to-tunnel/protocols.mdx index 3b05315f497600c..23dcae0a2db9ac2 100644 --- a/src/content/docs/cloudflare-one/networks/connectors/cloudflare-tunnel/routing-to-tunnel/protocols.mdx +++ b/src/content/docs/cloudflare-one/networks/connectors/cloudflare-tunnel/routing-to-tunnel/protocols.mdx @@ -7,19 +7,15 @@ sidebar: tableOfContents: false --- +import { Render } from "~/components"; -When you [add a published application route](/cloudflare-one/networks/connectors/cloudflare-tunnel/get-started/create-remote-tunnel/#2a-publish-an-application) to a Cloudflare Tunnel, you are instructing Cloudflare to proxy requests for your public hostname to a service running privately behind `cloudflared`. The table below lists the service types that can route to a public hostname. Non-HTTP services will require [installing `cloudflared` on the client](/cloudflare-one/access-controls/applications/non-http/cloudflared-authentication/) for end users to connect. +When you [add a published application route](/cloudflare-one/networks/connectors/cloudflare-tunnel/get-started/create-remote-tunnel/#2a-publish-an-application) to a Cloudflare Tunnel, you are instructing Cloudflare to proxy requests for your public hostname to a service running privately behind `cloudflared`. -| Service type | Description | Example `service` value | -| ------------ | ----------- | ---------- | -| HTTP | Incoming requests to Cloudflare over HTTPS are proxied to the local web service via HTTP. | `http://localhost:8000` | -| HTTPS | Incoming requests to Cloudflare over HTTPS are proxied directly to the local web service. You can [disable TLS verification](/cloudflare-one/networks/connectors/cloudflare-tunnel/configure-tunnels/cloudflared-parameters/origin-parameters/#notlsverify) if your origin uses self-signed certificates. | `https://localhost:8000` | -| UNIX | Just like HTTP, but using a Unix socket instead. | `unix:/home/production/echo.sock` | -| TCP | Enables TCP streams over a Websocket connection. `cloudflared` will take the packets received from the Websocket and reach out to the origin using TCP. To [connect to the public hostname over arbitrary TCP](/cloudflare-one/access-controls/applications/non-http/cloudflared-authentication/arbitrary-tcp/), the user needs to run `cloudflared access tcp`, and there are no guarantees on how long the TCP tunnel will live. For long-lived connections, we recommend using [WARP-to-Tunnel](/cloudflare-one/networks/connectors/cloudflare-tunnel/private-net/cloudflared/) instead.| `tcp://localhost:2222` | -| SSH | Enables SSH streams over a Websocket connection. `cloudflared` will take the packets received from the Websocket and reach out to the origin using SSH. To [connect to the public hostname over SSH](/cloudflare-one/networks/connectors/cloudflare-tunnel/use-cases/ssh/ssh-cloudflared-authentication/), the client needs to run `cloudflared access ssh`, and there are no guarantees on how long the SSH connection will last. For long-lived connections, we recommend using [WARP-to-Tunnel](/cloudflare-one/networks/connectors/cloudflare-tunnel/use-cases/ssh/ssh-infrastructure-access/) instead. | `ssh://localhost:22` | -| RDP | Similar to TCP but for RDP streams only. For more information, refer to [Connect to RDP with client-side cloudflared](/cloudflare-one/networks/connectors/cloudflare-tunnel/use-cases/rdp/rdp-cloudflared-authentication/). | `rdp://localhost:3389` | -| UNIX + TLS | Just like HTTPS, but using a Unix socket instead. | `unix+tls:/home/production/echo.sock` | -| SMB | Similar to TCP but for SMB streams only. For more information, refer to [Connect to SMB with client-side cloudflared](/cloudflare-one/networks/connectors/cloudflare-tunnel/use-cases/smb/#connect-to-smb-server-with-cloudflared-access). | `smb://localhost:445` | -| HTTP_STATUS | Responds to all requests with the given HTTP status. | `http_status:404` | -| BASTION | `cloudflared` will act like a jumphost, allowing access to any local address. | `bastion` -| HELLO_WORLD | Test server for validating your Cloudflare Tunnel connection (for [locally managed tunnels](/cloudflare-one/networks/connectors/cloudflare-tunnel/do-more-with-tunnels/local-management/configuration-file/#file-structure-for-published-applications) only). | `hello_world` | + diff --git a/src/content/docs/cloudflare-one/networks/connectors/cloudflare-tunnel/routing-to-tunnel/public-load-balancers.mdx b/src/content/docs/cloudflare-one/networks/connectors/cloudflare-tunnel/routing-to-tunnel/public-load-balancers.mdx index d7cd7eebe825c5d..6b0bd3ecea4cfbc 100644 --- a/src/content/docs/cloudflare-one/networks/connectors/cloudflare-tunnel/routing-to-tunnel/public-load-balancers.mdx +++ b/src/content/docs/cloudflare-one/networks/connectors/cloudflare-tunnel/routing-to-tunnel/public-load-balancers.mdx @@ -19,40 +19,14 @@ When you add a [published application route](/cloudflare-one/networks/connectors ### Create a load balancer -To create a load balancer for Cloudflare Tunnel published applications: - -1. In the Cloudflare dashboard, go to the **Load Balancing** page. - - -2. Select **Create load balancer**. -3. Select **Public load balancer**. -4. Under **Select website**, select the domain of your published application route. -5. On the **Hostname** page, enter a hostname for the load balancer (for example, `lb.example.com`). -6. On the **Pools** page, select **Create a pool**. -7. Enter a descriptive name for the pool. For example, if you are configuring one pool per tunnel, the pool name can match your tunnel name. -8. To add a tunnel endpoint to the pool, configure the following fields: - - **Endpoint Name**: Name of the server that is running the application - - **Endpoint Address**: `.cfargotunnel.com`, where `` is replaced by your Tunnel ID. You can find the **Tunnel ID** in [Cloudflare One](https://one.dash.cloudflare.com) under **Networks** > **Connectors** > **Cloudflare Tunnels**. - - **Header value**: Hostname of your published application route (such as `app.example.com`). To find the hostname value, open your Cloudflare Tunnel configuration and go to the **Published application routes** tab. - - **Weight**: Assign a [weight](/load-balancing/understand-basics/traffic-steering/origin-level-steering/#weights) to the endpoint. If you only have one endpoint, enter `1`. - :::note - A single origin pool cannot have the same Tunnel UUID referenced twice. - ::: -9. On the **Pools** page, choose a **Fallback pool**. Refer to [Global traffic steering](/load-balancing/understand-basics/traffic-steering/steering-policies/) for information on how the load balancer routes traffic to pools. -10. (Recommended) On the **Monitors** page, attach a monitor to the tunnel endpoint. For example, if your application is HTTP or HTTPS, you can create an HTTPS monitor to poll the application: - - **Type**: _HTTPS_ - - **Path**: `/` - - **Port**: `443` - - **Expected Code(s)**: `200` - - **Header Name**: `Host` - - **Value**: `app.example.com` - - :::note - TCP monitors are not supported for tunnel endpoints. For a workaround, refer to [Monitors and TCP tunnel origins](#monitors-and-tcp-tunnel-origins). - ::: - -11. Save and deploy the load balancer. -12. To test the load balancer, access the application using the load balancer hostname (`lb.example.com`). + **Connectors** > **Cloudflare Tunnels**" + }} +/> Refer to the [Load Balancing documentation](/load-balancing/) for more details on load balancer settings and configurations. @@ -180,21 +154,13 @@ Here is an example of what your DNS records will look like before and after sett ### Monitors and TCP tunnel origins -If you have a tunnel to a port or SSH port, do not set up a [TCP monitor](/load-balancing/monitors/). Instead, set up a health check endpoint on the `cloudflared` host and create an HTTPS monitor. For example, you can use `cloudflared` to return a fixed HTTP status response: - -1. In your Cloudflare Tunnel, [add a published application route](/cloudflare-one/networks/connectors/cloudflare-tunnel/get-started/create-remote-tunnel/#2a-publish-an-application) to represent the health check endpoint: - - **Hostame**: Enter a hostname for the health check endpoint (for example, `health-check.example.com`) - - **Service Type**: _HTTP_STATUS_ - - **HTTP Status Code**: `200` -2. From the **Load Balancing** page, [create a monitor](/load-balancing/monitors/create-monitor/) with the following properties: - - **Type**: _HTTPS_ - - **Path**: `/` - - **Port**: `443` - - **Expected Code(s)**: `200` - - **Header Name**: `Host` - - **Value**: `health-check.example.com` - -You can now assign this monitor to your load balancer endpoint. The monitor will only verify that your server is reachable. It does not check whether the server is running and accepting requests. + ### Session affinity and replicas @@ -202,8 +168,10 @@ The load balancer does not distinguish between [replicas](/cloudflare-one/networ ### Local connection preference -If you notice traffic imbalances across endpoints in different locations, you may have to adjust your load balancer setup. - -When an end user sends a request to your application, Cloudflare routes their traffic using [Anycast routing](https://www.cloudflare.com/learning/cdn/glossary/anycast-network/) and their request typically goes to the nearest Cloudflare data center. Cloudflare Tunnel will prefer to serve the request using `cloudflared` connections in the same data center. This behavior can impact how connections are weighted and traffic is distributed. - -If you are running [`cloudflared` replicas](/cloudflare-one/networks/connectors/cloudflare-tunnel/configure-tunnels/tunnel-availability/), switch to separate Cloudflare tunnels so that you can have more granular control over [traffic steering](/load-balancing/understand-basics/traffic-steering/). + diff --git a/src/content/docs/cloudflare-one/networks/connectors/cloudflare-tunnel/troubleshoot-tunnels/common-errors.mdx b/src/content/docs/cloudflare-one/networks/connectors/cloudflare-tunnel/troubleshoot-tunnels/common-errors.mdx index 0130de838817599..1bd13690de778de 100644 --- a/src/content/docs/cloudflare-one/networks/connectors/cloudflare-tunnel/troubleshoot-tunnels/common-errors.mdx +++ b/src/content/docs/cloudflare-one/networks/connectors/cloudflare-tunnel/troubleshoot-tunnels/common-errors.mdx @@ -5,7 +5,7 @@ sidebar: order: 2 --- -import { Tabs, TabItem, GlossaryTooltip, Render } from "~/components"; +import { GlossaryTooltip, Render } from "~/components"; This section covers the most common errors you might encounter when connecting resources with Cloudflare Tunnel. If you do not see your issue listed below, refer to the [troubleshooting FAQ](/cloudflare-one/faq/troubleshooting/), view your [Tunnel logs](/cloudflare-one/networks/connectors/cloudflare-tunnel/monitor-tunnels/logs/), or [contact Cloudflare Support](/support/contacting-cloudflare-support/). @@ -20,215 +20,35 @@ You can check your tunnel's connection status either from Cloudflare One (by goi The tunnel status only reflects the connection between `cloudflared` and the Cloudflare network. Tunnel status does not indicate whether `cloudflared` can successfully reach your internal services. As a result, a tunnel can appear `Healthy` while users are still unable to connect to an application. ::: -## I see `cloudflared service is already installed`. - -If you see this error when installing a remotely-managed tunnel, ensure that no other `cloudflared` instances are running as a service on this machine. Only a single instance of `cloudflared` may run as a service on any given machine. Instead, we recommend adding additional routes to your existing tunnel. Alternatively, you can run `sudo cloudflared service uninstall` to uninstall `cloudflared`. - -## I see `An A, AAAA, or CNAME record with that host already exists`. - -If you are unable to save your tunnel's public hostname, choose a different hostname or delete the existing DNS record. [Check the DNS records](/dns/manage-dns-records/how-to/create-dns-records/) for your domain from the [Cloudflare dashboard](https://dash.cloudflare.com). - -## Tunnel credentials file doesn't exist or is not a file. - -If you encounter the following error when running a tunnel, double check your `config.yml` file and ensure that the `credentials-file` points to the correct location. You may need to change `/root/` to your home directory. - -```sh -cloudflared tunnel run -``` - -```sh output -2021-06-04T06:21:16Z INF Starting tunnel tunnelID=928655cc-7f95-43f2-8539-2aba6cf3592d -Tunnel credentials file '/root/.cloudflared/928655cc-7f95-43f2-8539-2aba6cf3592d.json' doesn't exist or is not a file -``` - -## My tunnel fails to authenticate. - -To start using Cloudflare Tunnel, a super administrator in the Cloudflare account must first log in through `cloudflared login`. The client will launch a browser window and prompt the user to select a hostname in their Cloudflare account. Once selected, Cloudflare generates a certificate that consists of three components: - -- The public key of the origin certificate for that hostname -- The private key of the origin certificate for that domain -- A token that is unique to Cloudflare Tunnel - -Those three components are bundled into a single PEM file that is downloaded one time during that login flow. The host certificate is valid for the root domain and any subdomain one-level deep. Cloudflare uses that certificate file to authenticate `cloudflared` to create DNS records for your domain in Cloudflare. - -The third component, the token, consists of the zone ID (for the selected domain) and an API token scoped to the user who first authenticated with the login command. When user permissions change (if that user is removed from the account or becomes an admin of another account, for example), Cloudflare rolls the user's API key. However, the certificate file downloaded through `cloudflared` retains the older API key and can cause authentication failures. The user will need to login once more through `cloudflared` to regenerate the certificate. Alternatively, the administrator can create a dedicated service user to authenticate. - -## I see an error: x509: certificate signed by unknown authority. - -This means the origin is using a certificate that `cloudflared` does not trust. For example, you may get this error if you are using SSL/TLS inspection in a proxy between your server and Cloudflare. To solve this: - -- Add the certificate to the system certificate pool. -- Use the `--origin-ca-pool` flag and specify the path to the certificate. -- Use the `--no-tls-verify` flag to stop `cloudflared` checking the certificate for a trust chain. - -## I see an error 1033 when attempting to run a tunnel. - - - -For more information, refer to the [comprehensive list](/support/troubleshooting/http-status-codes/cloudflare-1xxx-errors/) of Cloudflare 1xxx errors. - -## I see a 502 Bad Gateway error when connecting to an HTTP or HTTPS application through tunnel. - -A `502 Bad Gateway` error with `Unable to reach the origin service. The service may be down or it may not be responding to traffic from cloudflared` on a tunnel route means the tunnel itself is connected to the Cloudflare network, but `cloudflared` cannot reach the origin service defined in your ingress rule. Unlike [error 1033](#i-see-an-error-1033-when-attempting-to-run-a-tunnel), which indicates the tunnel is not connected to Cloudflare, a 502 error indicates the problem is between `cloudflared` and your local service. - -To identify the specific cause, review your [Tunnel logs](/cloudflare-one/networks/connectors/cloudflare-tunnel/monitor-tunnels/logs/) for `error`-level messages. Common causes include: - -### Origin service is not running - -If the origin service has stopped or never started, `cloudflared` logs will show an error similar to: - -```txt -error="dial tcp [::1]:8080: connect: connection refused" -``` - -To resolve, verify the service is running and listening on the expected port: - -```sh -curl -v http://localhost:8080 -``` - -If the service is not running, start or restart it. You can confirm the service is listening by running `ss -tlnp | grep ` (Linux) or `lsof -iTCP -sTCP:LISTEN -nP | grep ` (macOS). - -### Origin service URL uses the wrong protocol - -If the origin expects HTTPS but the [published application route](/cloudflare-one/networks/connectors/cloudflare-tunnel/get-started/create-remote-tunnel/#2a-publish-an-application) specifies `http://`, or vice versa, `cloudflared` logs will show an error similar to: - -```txt -error="net/http: HTTP/1.x transport connection broken: malformed HTTP response \"\x15\x03\x01\x00\x02\x02\"" -``` - -To resolve, update the `service` field in your published application route to match the [protocol](/cloudflare-one/networks/connectors/cloudflare-tunnel/routing-to-tunnel/protocols/) your origin expects. For example, change `http://localhost:8080` to `https://localhost:8080`. If you are using a locally-managed tunnel, update your ingress rule in the [configuration file](/cloudflare-one/networks/connectors/cloudflare-tunnel/do-more-with-tunnels/local-management/configuration-file/#file-structure-for-published-applications). - -### Origin service URL points to the wrong port - -If the port in your [published application route](/cloudflare-one/networks/connectors/cloudflare-tunnel/get-started/create-remote-tunnel/#2a-publish-an-application) does not match the port your service is listening on, `cloudflared` will log a `connection refused` error for that port. Double-check the `service` URL in your ingress rule and compare it against the port your application is bound to. - -### Origin uses a certificate that `cloudflared` does not trust - -If the origin presents a TLS certificate that `cloudflared` cannot verify, the logs will show an error similar to: - -```txt -error="x509: certificate is valid for example.com, not localhost" -``` - -This commonly occurs when the origin uses a self-signed certificate or when an SSL/TLS inspection proxy sits between `cloudflared` and the origin. - -To resolve, use one of the following approaches: - -- Set [`originServerName`](/cloudflare-one/networks/connectors/cloudflare-tunnel/configure-tunnels/cloudflared-parameters/origin-parameters/#originservername) to the hostname on the origin certificate in your [published application route](/cloudflare-one/networks/connectors/cloudflare-tunnel/get-started/create-remote-tunnel/#2a-publish-an-application). If you are using a locally-managed tunnel, here is an example of a [configuration file](/cloudflare-one/networks/connectors/cloudflare-tunnel/do-more-with-tunnels/local-management/configuration-file/): - - ```yml - ingress: - - hostname: app.example.com - service: https://localhost:443 - originRequest: - originServerName: app.example.com - ``` - -- Provide the CA certificate using [`caPool`](/cloudflare-one/networks/connectors/cloudflare-tunnel/configure-tunnels/cloudflared-parameters/origin-parameters/#capool): - - ```yml - ingress: - - hostname: app.example.com - service: https://localhost:443 - originRequest: - caPool: /path/to/ca-cert.pem - ``` - -- As a last resort, disable TLS verification with [`noTLSVerify`](/cloudflare-one/networks/connectors/cloudflare-tunnel/configure-tunnels/cloudflared-parameters/origin-parameters/#notlsverify). This is not recommended for production environments. - - ```yml - ingress: - - hostname: app.example.com - service: https://localhost:443 - originRequest: - noTLSVerify: true - ``` - -## I see `ERR_TOO_MANY_REDIRECTS` when attempting to connect to an Access self-hosted app. - -This error occurs when `cloudflared` does not recognize the SSL/TLS certificate presented by your origin. To resolve the issue, set the [origin server name](/cloudflare-one/networks/connectors/cloudflare-tunnel/configure-tunnels/cloudflared-parameters/origin-parameters/#originservername) parameter to the hostname on your origin certificate. Here is an example of a locally-managed tunnel configuration: - -```txt -ingress: - - hostname: test.example.com - service: https://localhost:443 - originRequest: - originServerName: test.example.com -``` - -## `cloudflared access` shows an error `websocket: bad handshake`. - -This means that your `cloudflared access` client is unable to reach your `cloudflared tunnel` origin. -To diagnose this, you should look at the `cloudflared tunnel` logs. A very often root cause is that the `cloudflared tunnel` is unable to proxy to your origin (e.g. because the ingress is mis-configured, or the origin is down, or because the origin HTTPS certificate cannot be validated by `cloudflared tunnel`). -If `cloudflared tunnel` has no logs, it means Cloudflare Edge is not even able to route the websocket traffic to it. - -There are a few different possible root causes behind the `websocket: bad handshake` error: - -- Your `cloudflared tunnel` is either not running or not connected to Cloudflare Edge. - -- WebSockets are not [enabled](/network/websockets/#enable-websockets). - -- Your Cloudflare account has Universal SSL enabled but your SSL/TLS encryption mode is set to **Off (not secure)**. To resolve: - 1. On the Cloudflare dashboard for your zone, go to **SSL/TLS** > **Overview**. - 2. Ensure that your SSL/TLS encryption mode is set to either **Flexible**, **Full** or **Full (strict)**. - -- Your requests are blocked by [Super Bot Fight Mode](/bots/get-started/super-bot-fight-mode/). To resolve, make sure you set **Definitely automated** to _Allow_ in the bot fight mode settings. - -- Your SSH or RDP Access application has the [Binding Cookie](/cloudflare-one/access-controls/applications/http-apps/authorization-cookie/#binding-cookie) enabled. To disable the cookie, go to **Access controls** > **Applications** and edit the application settings. - -- One or more [Workers routes](/workers/configuration/routing/routes/) are overlapping with the tunnel hostname, and the Workers do not properly handle the traffic. To resolve, you could either exclude your tunnel from the Worker route by not defining a route that includes the tunnel's hostname or update your Worker to only handle specific paths and forward all other requests to the origin, for example, by using `return fetch(req)`. + ## My tunnel randomly disconnects. Long-lived connections initiated through Cloudflare One, such as SSH sessions, can last up to eight hours. However, disruptions along the service path may result in more frequent disconnects. Often, these disconnects are caused by regularly scheduled maintenance events such as data center, server, or service updates and restarts. If you believe these events are not the cause of disconnects in your environment, collect the relevant [WARP logs](/cloudflare-one/team-and-resources/devices/warp/troubleshooting/warp-logs/) and [Tunnel logs](/cloudflare-one/networks/connectors/cloudflare-tunnel/monitor-tunnels/logs/) and contact Support. -## Tunnel connections fail with SSL error. - -If `cloudflared` returns error `error="remote error: tls: handshake failure"`, check to make sure the hostname in question is covered by a SSL certificate. If using a multi-level subdomain, an advanced certificate may be required as the Universal SSL will not cover more than one level of subdomain. This may surface in the browser as `ERR_SSL_VERSION_OR_CIPHER_MISMATCH`. - -## Tunnel connections fail with `Too many open files` error. - -If your [Cloudflare Tunnel logs](/cloudflare-one/networks/connectors/cloudflare-tunnel/monitor-tunnels/logs/) returns a `socket: too many open files` error, it means that `cloudflared` has exhausted the open files limit on your machine. The maximum number of open files, or file descriptors, is an operating system setting that determines how many files a process is allowed to open. To increase the open file limit, you will need to [configure ulimit settings](/cloudflare-one/networks/connectors/cloudflare-tunnel/configure-tunnels/tunnel-availability/system-requirements/#ulimits) on the machine running `cloudflared`. - -## I see `failed to sufficiently increase receive buffer size` in my cloudflared logs. - -This buffer size increase is reported by the [quic-go library](https://github.com/quic-go/quic-go) leveraged by [cloudflared](https://github.com/cloudflare/cloudflared). You can learn more about the log message in the [quic-go repository](https://github.com/quic-go/quic-go/wiki/UDP-Buffer-Sizes). This log message is generally not impactful and can be safely ignored when troubleshooting. However, if you have deployed `cloudflared` within a unique, high-bandwidth environment then buffer size can be manually overridden for testing purposes. - -To set the maximum receive buffer size on Linux: - -1. Create a new file under `/etc/sysctl.d/`: - -```sh -sudo vi 98-core-rmem-max.conf -``` - -2. In the file, define the desired buffer size: - -```txt -net.core.rmem_max=2500000 -``` - -3. Reboot the host machine running `cloudflared`. - -4. To validate that these changes have taken effect, use the `grep` command: - -```sh -sudo sysctl -a | grep net.core.rmem_max -``` - -```sh output -net.core.rmem_max = 2500000 -``` - ## `ping` and `traceroute` commands do not work. To ping an IP address behind Cloudflare Tunnel, your system must allow ICMP traffic through `cloudflared`. For configuration instructions, refer to the [ICMP proxy documentation](/cloudflare-one/traffic-policies/proxy/#icmp). -## Cloudflare Tunnel is buffering my streaming response instead of streaming it live. - -Proxied traffic through Cloudflare Tunnel is buffered by default unless the origin server includes the response header `Content-Type: text/event-stream`. The `Content-Type: text/event-stream` response header tells `cloudflared` to stream data as it arrives instead of buffering the entire response. - ## I see `Error: This route's network is inside an existing subnet's network at "100.96.0.0/12"`. This error occurs when you try to add a CIDR route that falls within Cloudflare WARP's CGNAT IP range. The `100.96.0.0/12` range, which covers addresses from `100.96.0.1` to `100.111.255.254`, is reserved for internal WARP routing and cannot be added as a Cloudflare Tunnel route. To connect your private network, you will need to change its IP/CIDR so that it does not overlap with `100.96.0.0/12`. diff --git a/src/content/docs/cloudflare-one/networks/connectors/cloudflare-tunnel/troubleshoot-tunnels/diag-logs.mdx b/src/content/docs/cloudflare-one/networks/connectors/cloudflare-tunnel/troubleshoot-tunnels/diag-logs.mdx index adacaa18dff316e..54ed41511daac4f 100644 --- a/src/content/docs/cloudflare-one/networks/connectors/cloudflare-tunnel/troubleshoot-tunnels/diag-logs.mdx +++ b/src/content/docs/cloudflare-one/networks/connectors/cloudflare-tunnel/troubleshoot-tunnels/diag-logs.mdx @@ -22,113 +22,45 @@ The steps for getting diagnostic logs depend on your `cloudflared` deployment en These instructions apply to remotely-managed and locally-managed tunnels running directly on the host machine. -1. (Linux only) To include network diagnostics in the logs, allow the `cloudflared` user to create RAW and PACKET sockets without root permissions: - - ```sh - sudo setcap cap_net_raw+ep /usr/bin/traceroute && sudo setcap cap_net_raw+ep /usr/bin/traceroute - ``` - - If you do not set `cap_net_raw`, then traceroute data will be unavailable. - -2. Get diagnostic logs: - - ```sh - cloudflared tunnel diag - ``` - - If multiple instances of `cloudflared` are running on the same host, specify the [metrics server IP and port](/cloudflare-one/networks/connectors/cloudflare-tunnel/monitor-tunnels/metrics/#configure-the-metrics-server-address) for the instance you want to diagnose. For example: - - ```sh - cloudflared tunnel diag --metrics 127.0.0.1:20241 - ``` - -This command will output the status of each diagnostic task and place a `cloudflared-diag-YYYY-MM-DDThh-mm-ss.zip` file in your working directory. + ### Docker -`cloudflared` reads diagnostic data from the [tunnel metrics server](/cloudflare-one/networks/connectors/cloudflare-tunnel/monitor-tunnels/metrics/). To get diagnostic logs, the metrics server must be exposed from the Docker container and reachable from the host machine. - -1. Determine the [metrics server port](/cloudflare-one/networks/connectors/cloudflare-tunnel/monitor-tunnels/metrics/#default-metrics-server-address) for the `cloudflared` instance running in Docker. - -2. Ensure the container is deployed with port forwarding enabled. The diagnostic feature will request information from the Docker instance using local port `20241`, therefore you should forward port `20241` to the container port obtained in Step 1: - - ```sh - docker run -d -p 20241: docker.io/cloudflare/cloudflared tunnel ... - ``` - -3. Verify that you can reach the metrics server address from the Docker host environment: - - ```sh - curl localhost:20241/diag/tunnel - ``` - - This command should return a JSON: - ```json - { - "tunnelID": "ef96b330-a7f5-4bce-a00e-827ce5be077f", - "connectorID": "d236670a-9f74-422f-adf1-030f5c5f0523", - "connections": [ - { "isConnected": true, "protocol": 1, "edgeAddress": "198.41.192.167"}, - {"isConnected": true, "protocol": 1, "edgeAddress": "198.41.200.113", "index": 1}, - {"isConnected": true, "protocol": 1, "edgeAddress": "198.41.192.47", "index": 2}, - {"isConnected": true, "protocol": 1, "edgeAddress": "198.41.200.73", "index": 3} - ], - "icmp_sources": ["192.168.1.243", "fe80::c59:bd4a:e815:ed6"] - } - ``` - -4. Run the diagnostic using the Docker container ID: - - ```sh - cloudflared tunnel diag --diag-container-id= - ``` - - Alternatively, you can specify the container's name instead of its ID: - ```sh - cloudflared tunnel diag --diag-container-id= - ``` - - Running the diagnostic command with the container ID allows `cloudflared` to collect information from the Docker environment such as logs and container details. - -This command will output the status of each diagnostic task and place a `cloudflared-diag-YYYY-MM-DDThh-mm-ss.zip` file in your working directory. + ### Kubernetes -The diagnostic feature will request data from the [tunnel metrics server](/cloudflare-one/networks/connectors/cloudflare-tunnel/monitor-tunnels/metrics/) using ports `20241` to `20245`. You will need to use port forwarding to allow the local `cloudflared` instance to connect to the metrics server on one of these ports. - -1. Determine the tunnel's [metrics server port](/cloudflare-one/networks/connectors/cloudflare-tunnel/monitor-tunnels/metrics/#default-metrics-server-address). - -2. Enable port forwarding: - - ```sh - kubectl port-forward : - ``` - - - ``: Name of the pod where the tunnel is running - - `` is any local port in the range `20241` to `20245`. - - `` is the Kubernetes pod port for the `cloudflared` instance you want to diagnose (obtained in Step 1). - - For example, if you set the metrics server address to `0.0.0.0:12345`: - - ```sh - kubectl port-forward cloudflared-6d4897585b-r8kfz 20244:12345 - ``` - Connections made to local port `20244` are forwarded to port `12345` of the pod that is running the tunnel. - -3. Run the diagnostic: - - ```sh - cloudflared tunnel diag --diag-pod-id= - ``` - - If the pod has multiple applications/services running and `cloudflared` is not the first in the pod, you must specify either the container ID or name: - - ```sh - cloudflared tunnel diag --diag-pod-id= --diag-container-id= - ``` - -This command will output the status of each diagnostic task and place a `cloudflared-diag-YYYY-MM-DDThh-mm-ss.zip` file in your working directory. + ## cloudflared-diag files - + diff --git a/src/content/docs/reference-architecture/design-guides/extending-cloudflares-benefits-to-saas-providers-end-customers.mdx b/src/content/docs/reference-architecture/design-guides/extending-cloudflares-benefits-to-saas-providers-end-customers.mdx index 62117b87fce67f9..bc07236d8165e63 100644 --- a/src/content/docs/reference-architecture/design-guides/extending-cloudflares-benefits-to-saas-providers-end-customers.mdx +++ b/src/content/docs/reference-architecture/design-guides/extending-cloudflares-benefits-to-saas-providers-end-customers.mdx @@ -1,7 +1,7 @@ --- title: Extend Cloudflare's benefits to SaaS providers' end-customers pcx_content_type: design-guide -products: [cloudflare-tunnel, cloudflare-for-saas, load-balancing, data-localization] +products: [tunnel, cloudflare-for-saas, load-balancing, data-localization] sidebar: order: 1 label: Cloudflare's benefits for SaaS providers @@ -53,7 +53,7 @@ The following products are used to deliver this solution. | [DDoS Protection](/ddos-protection/) | Volumetric attack protection is automatically enabled for [proxied](/dns/proxy-status/) hostnames. | | [Regional Services](/data-localization/regional-services/) (part of the Data Localization Suite) | Restrict inspection of data (processing) to only those data centers within jurisdictional boundaries. | | [Load Balancer](/load-balancing/) | Distributes traffic across your endpoints, which reduces endpoint strain and latency and improves the experience for end users. | -| [Cloudflare Tunnel](/cloudflare-one/networks/connectors/cloudflare-tunnel/) | Secure method to connect to customers' networks and servers without creating holes in [firewalls](/cloudflare-one/networks/connectors/cloudflare-tunnel/configure-tunnels/tunnel-with-firewall/). cloudflared is the daemon (software) installed on origin servers to create a secure tunnel from applications back to Cloudflare. | +| [Cloudflare Tunnel](/cloudflare-one/networks/connectors/cloudflare-tunnel/) | Secure method to connect to customers' networks and servers without creating holes in [firewalls](/cloudflare-one/networks/connectors/cloudflare-tunnel/configure-tunnels/tunnel-with-firewall/). cloudflared is the daemon (software) installed on origin servers to create a secure tunnel from applications back to Cloudflare. | ## Cloudflare for SaaS examples diff --git a/src/content/docs/reference-architecture/design-guides/leveraging-cloudflare-for-your-saas-applications.mdx b/src/content/docs/reference-architecture/design-guides/leveraging-cloudflare-for-your-saas-applications.mdx index 4b71c3e10f4b167..dc50f2c60a8f67d 100644 --- a/src/content/docs/reference-architecture/design-guides/leveraging-cloudflare-for-your-saas-applications.mdx +++ b/src/content/docs/reference-architecture/design-guides/leveraging-cloudflare-for-your-saas-applications.mdx @@ -1,8 +1,7 @@ --- title: Leveraging Cloudflare for your SaaS applications pcx_content_type: design-guide -products: - [cloudflare-for-saas, cloudflare-tunnel, load-balancing, data-localization] +products: [cloudflare-for-saas, tunnel, load-balancing, data-localization] sidebar: order: 1 label: Leveraging Cloudflare for your SaaS applications diff --git a/src/content/docs/tunnel/advanced/index.mdx b/src/content/docs/tunnel/advanced/index.mdx new file mode 100644 index 000000000000000..8fe5273c22a48e1 --- /dev/null +++ b/src/content/docs/tunnel/advanced/index.mdx @@ -0,0 +1,12 @@ +--- +pcx_content_type: navigation +title: Advanced +sidebar: + order: 9 + group: + hideIndex: true +--- + +import { DirectoryListing } from "~/components"; + + diff --git a/src/content/docs/tunnel/advanced/local-management/as-a-service/index.mdx b/src/content/docs/tunnel/advanced/local-management/as-a-service/index.mdx new file mode 100644 index 000000000000000..93da2df62587c70 --- /dev/null +++ b/src/content/docs/tunnel/advanced/local-management/as-a-service/index.mdx @@ -0,0 +1,15 @@ +--- +pcx_content_type: navigation +title: Run as a service +sidebar: + order: 4 + +--- + +import { DirectoryListing } from "~/components" + +You can install `cloudflared` as a system service on Linux and Windows, and as a launch agent on macOS. In most cases, we recommend running `cloudflared` as a service. Running as a service helps ensure the availability of `cloudflared` to your origin by allowing the program to start at boot and continue running while your origin is online. + +Follow our guides to set up and run `cloudflared` as a service in your environment: + + diff --git a/src/content/docs/tunnel/advanced/local-management/as-a-service/linux.mdx b/src/content/docs/tunnel/advanced/local-management/as-a-service/linux.mdx new file mode 100644 index 000000000000000..44367766ac9ed36 --- /dev/null +++ b/src/content/docs/tunnel/advanced/local-management/as-a-service/linux.mdx @@ -0,0 +1,61 @@ +--- +pcx_content_type: how-to +title: Linux +sidebar: + order: 31 +head: + - tag: title + content: Run as a service on Linux +--- + +You can install `cloudflared` as a system service on Linux. + +## Prerequisites + +Before you install Cloudflare Tunnel as a service on Linux, follow Steps 1 through 4 of the [Tunnel CLI setup guide](/tunnel/other-tunnel-types/local-management/create-local-tunnel/). At this point you should have a named tunnel and a `config.yml` file in your `.cloudflared` directory. + +## 1. Configure `cloudflared` as a service + +By default, Cloudflare Tunnel expects all of the configuration to exist in the `$HOME/.cloudflared/config.yml` [configuration file](/tunnel/other-tunnel-types/local-management/configuration-file/). At a minimum you must specify the following arguments to run as a service: + +| Argument | Description | +| ------------------ | ---------------------------------------------------- | +| `tunnel` | The UUID of your tunnel | +| `credentials-file` | The location of the credentials file for your Tunnel | + +## 2. Run `cloudflared` as a service + +1. Install the `cloudflared` service. + + ```sh + cloudflared service install + ``` + + :::note + Installing the `cloudflared` systemd service on Linux typically requires elevated privileges. When the install command is run with `sudo`, `$HOME` points to `/root`, which may prevent `cloudflared` from locating a configuration file created in `/home//.cloudflared/config.yml`. In this case, the config path can be passed explicitly: + + ```sh + sudo cloudflared --config /home//.cloudflared/config.yml service install + ``` + + ::: + +2. Start the service. + + ```sh + systemctl start cloudflared + ``` + +3. (Optional) View the status of the service. + + ```sh + systemctl status cloudflared + ``` + +## Next steps + +You can now [route traffic through your tunnel](/tunnel/other-tunnel-types/local-management/create-local-tunnel/#5-start-routing-traffic). If you add IP routes or otherwise change the configuration, restart the service to load the new configuration: + +```sh +systemctl restart cloudflared +``` diff --git a/src/content/docs/tunnel/advanced/local-management/as-a-service/macos.mdx b/src/content/docs/tunnel/advanced/local-management/as-a-service/macos.mdx new file mode 100644 index 000000000000000..d0e98526d3c9a1a --- /dev/null +++ b/src/content/docs/tunnel/advanced/local-management/as-a-service/macos.mdx @@ -0,0 +1,67 @@ +--- +pcx_content_type: how-to +title: macOS +sidebar: + order: 31 +head: + - tag: title + content: Run as a service on macOS +--- + +You can install `cloudflared` as a system service on macOS. + +## Prerequisites + +Before you install Cloudflare Tunnel as a service on your OS, follow Steps 1 through 4 of the [Tunnel CLI setup guide](/tunnel/other-tunnel-types/local-management/create-local-tunnel/). At this point you should have a named tunnel and a `config.yml` file in your `$HOME/.cloudflared` directory. + +## 1. Configure `cloudflared` as a service + +By default, Cloudflare Tunnel expects all of the configuration to exist in the `$HOME/.cloudflared/config.yml` [configuration file](/tunnel/other-tunnel-types/local-management/configuration-file/). At a minimum you must specify the following arguments to run as a service: + +| Argument | Description | +| ------------------ | ---------------------------------------------------- | +| `tunnel` | The UUID of your tunnel | +| `credentials-file` | The location of the credentials file for your tunnel | + +## 2. Run `cloudflared` as a service + +You can install the service to either run at login or at boot. + +### Run at login + +Open a terminal window and run the following command: + +```sh +cloudflared service install +``` + +Cloudflare Tunnel will be installed as a launch agent and start whenever you log in, using your local user configuration found in `~/.cloudflared/`. + +### Run at boot + +Open a terminal window and run the following command: + +```sh +sudo cloudflared service install +``` + +Cloudflare Tunnel will be installed as a launch daemon and start whenever your system boots, using your configuration found in `/etc/cloudflared`. + +## 3. Manually start the service + +Run the following command: + +```sh +sudo launchctl start com.cloudflare.cloudflared +``` + +The output will be logged to `/Library/Logs/com.cloudflare.cloudflared.err.log` and `/Library/Logs/com.cloudflare.cloudflared.out.log`. + +## Next steps + +You can now [route traffic through your tunnel](/tunnel/other-tunnel-types/local-management/create-local-tunnel/#5-start-routing-traffic). If you add IP routes or otherwise change the configuration, restart the service to load the new configuration: + +```sh +sudo launchctl stop com.cloudflare.cloudflared +sudo launchctl start com.cloudflare.cloudflared +``` diff --git a/src/content/docs/tunnel/advanced/local-management/as-a-service/windows.mdx b/src/content/docs/tunnel/advanced/local-management/as-a-service/windows.mdx new file mode 100644 index 000000000000000..ef34862fd345a28 --- /dev/null +++ b/src/content/docs/tunnel/advanced/local-management/as-a-service/windows.mdx @@ -0,0 +1,132 @@ +--- +pcx_content_type: how-to +title: Windows +sidebar: + order: 31 +head: + - tag: title + content: Run as a service on Windows +--- + +You can install `cloudflared` as a system service on Windows. + +## Configure `cloudflared` as a service + +By default, Cloudflare Tunnel expects all of the configuration to exist in the `%USERPROFILE%\.cloudflared\config.yml` [configuration file](/tunnel/other-tunnel-types/local-management/configuration-file/). At a minimum you must specify the following arguments to run as a service: + +| Argument | Description | +| ------------------ | ---------------------------------------------------- | +| `tunnel` | The UUID of your tunnel | +| `credentials-file` | The location of the credentials file for your tunnel | + +## Run `cloudflared` as a service + +1. [Download](/tunnel/downloads/) the latest `cloudflared` version. + +2. Create a new directory: + + ```bash + C:\Cloudflared\bin + ``` + +3. Copy the `.exe` file you downloaded in step 1 to the new directory and rename it to `cloudflared.exe`. + +4. Open CMD as an administrator and go to `C:\Cloudflared\bin`. + +5. Run this command to install `cloudflared`: + + ```bash + cloudflared.exe service install + ``` + +6. Next, run this command to create another directory: + + ```bash + mkdir C:\Windows\System32\config\systemprofile\.cloudflared + ``` + +7. Log in and authenticate `cloudflared`: + + ```bash + cloudflared.exe login + ``` + +8. The login command will generate a `cert.pem` file and save it to your user profile by default. Copy the file to the `.cloudflared` folder created in step 5 using this command: + + ```bash + copy C:\Users\%USERNAME%\.cloudflared\cert.pem C:\Windows\System32\config\systemprofile\.cloudflared\cert.pem + ``` + +9. Next, create a tunnel: + + ```bash + cloudflared.exe tunnel create + ``` + + This will generate a [credentials file](/tunnel/other-tunnel-types/local-management/local-tunnel-terms/#credentials-file) in `.json` format. + +10. [Create a configuration file](/tunnel/other-tunnel-types/local-management/create-local-tunnel/#4-create-a-configuration-file) with the following content: + + ```txt + tunnel: + credentials-file: C:\Windows\System32\config\systemprofile\.cloudflared\.json + # Uncomment the following two lines if you are using self-signed certificates in your origin server + # originRequest: + # noTLSVerify: true + + ingress: + - hostname: app.mydomain.com + service: https://internal.mydomain.com + - service: http_status:404 + logfile: C:\Cloudflared\cloudflared.log + ``` + +11. Copy the credentials file to the folder created in step 6: + + ```bash + copy C:\Users\%USERNAME%\.cloudflared\.json C:\Windows\System32\config\systemprofile\.cloudflared\.json + ``` + +12. Validate the ingress rule entries in your configuration file using the command: + + ```bash + cloudflared.exe tunnel ingress validate + ``` + +13. In the Registry Editor, go to `Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Cloudflared`. + +14. In the Cloudflared registry entry, modify `ImagePath` to point to the `cloudflared.exe` and `config.yml` files. Make sure that there are no extra spaces or characters while you modify the registry entry, as this could cause problems with starting the service. + + ```bash + C:\Cloudflared\bin\cloudflared.exe --config=C:\Windows\System32\config\systemprofile\.cloudflared\config.yml tunnel run + ``` + +15. If the service does not start, run the following command from `C:\Cloudflared\bin`: + + ```bash + sc start cloudflared + ``` + + You will see the output below: + + ```txt + SERVICE_NAME: cloudflared + TYPE : 10 WIN32_OWN_PROCESS + STATE : 2 START_PENDING + (NOT_STOPPABLE, NOT_PAUSABLE, IGNORES_SHUTDOWN) + WIN32_EXIT_CODE : 0 (0x0) + SERVICE_EXIT_CODE : 0 (0x0) + CHECKPOINT : 0x0 + WAIT_HINT : 0x7d0 + PID : 3548 + FLAGS : + ``` + +## Next steps + +You can now [route traffic through your tunnel](/tunnel/other-tunnel-types/local-management/create-local-tunnel/#5-start-routing-traffic). If you add IP routes or otherwise change the configuration, restart the service to load the new configuration: + +```bash +sc stop cloudflared +sc start cloudflared +``` diff --git a/src/content/docs/tunnel/advanced/local-management/configuration-file.mdx b/src/content/docs/tunnel/advanced/local-management/configuration-file.mdx new file mode 100644 index 000000000000000..784c2967ad7b622 --- /dev/null +++ b/src/content/docs/tunnel/advanced/local-management/configuration-file.mdx @@ -0,0 +1,166 @@ +--- +pcx_content_type: reference +title: Configuration file +sidebar: + order: 2 +--- + +:::note + +[Quick tunnels](/tunnel/faq/#quick-tunnels) do not need a configuration file. + +::: + +Locally-managed tunnels run as an instance of `cloudflared` on your machine. You can configure `cloudflared` properties by modifying [command line parameters](/tunnel/configuration/#run-parameters) or by editing the tunnel [configuration file](/tunnel/other-tunnel-types/local-management/create-local-tunnel/#4-create-a-configuration-file). + +The CLI provides a quick way to handle configurations if you are connecting a single service through `cloudflared`. The tunnel configuration file is useful if you are connecting multiple services and need to configure properties or exceptions for specific origins. In the configuration file, you can define top-level properties for your `cloudflared` instance as well as [origin-specific properties](/tunnel/configuration/#origin-parameters). For a full list of configuration options, type `cloudflared tunnel help` in your terminal. + +In the absence of a configuration file, `cloudflared` will proxy outbound traffic through port `8080`. + +:::note +To configure `warp-routing` for private network access via Zero Trust, refer to the [Cloudflare Tunnel for SASE configuration file documentation](/cloudflare-one/networks/connectors/cloudflare-tunnel/do-more-with-tunnels/local-management/configuration-file/#file-structure-for-private-networks). +::: + +## File structure for published applications + +If you are exposing local services to the Internet, you can assign a public hostname to each service: + +```yml +tunnel: 6ff42ae2-765d-4adf-8112-31c55c1551ef +credentials-file: /root/.cloudflared/6ff42ae2-765d-4adf-8112-31c55c1551ef.json + +ingress: + - hostname: gitlab.widgetcorp.tech + service: http://localhost:80 + - hostname: gitlab-ssh.widgetcorp.tech + service: ssh://localhost:22 + - service: http_status:404 +``` + +Configuration files that contain ingress rules must always include a catch-all rule that concludes the file. In this example, `cloudflared` will respond with a `404` status code when the request does not match any of the previous hostnames. + +### How traffic is matched + +When `cloudflared` receives an incoming request, it evaluates each ingress rule from top to bottom to find which rule matches the request. Rules can match either the hostname or path of an incoming request, or both. If a rule does not specify a hostname, all hostnames will be matched. If a rule does not specify a path, all paths will be matched. + +The last ingress rule must be a catch-all rule that matches all traffic. + +Here is an example configuration file that specifies several rules: + +```yml +tunnel: 6ff42ae2-765d-4adf-8112-31c55c1551ef +credentials-file: /root/.cloudflared/6ff42ae2-765d-4adf-8112-31c55c1551ef.json + +ingress: + # Rules map traffic from a hostname to a local service: + - hostname: example.com + service: https://localhost:8000 + # Rules can match the request's path to a regular expression: + - hostname: static.example.com + path: \.(jpg|png|css|js)$ + service: https://localhost:8001 + # Rules can match the request's hostname to a wildcard character: + - hostname: "*.example.com" + service: https://localhost:8002 + # An example of a catch-all rule: + - service: https://localhost:8003 +``` + +#### Wildcards + +You can use wildcards to match traffic to multiple subdomains. For example, if you set the `hostname` key to `*.example.com`, both `alpha.example.com` and `beta.example.com` will route traffic to your origin. `cloudflared` does not support wildcards in the middle of the hostname, such as `test.*.example.com`. + +You can also enter regular expressions for the `path` key. For example, if `hostname` is `static.example.com` and `path` is `\.(jpg|png|css|js)$`, matching URLs could include `https://static.example.com/data.js`, `http://static.example.com/images/photo.jpg`, and so on. Cloudflare parses the path regex using the [Go `syntax` package](https://pkg.go.dev/regexp/syntax). + +### Services + +In addition to HTTP, `cloudflared` supports protocols like SSH, RDP, arbitrary TCP services, and Unix sockets. You can also route traffic to the built-in `hello_world` test server or respond to traffic with an HTTP status. For a full list of supported service types, refer to [Protocols for published applications](/tunnel/routing/#supported-protocols). + +```yml +tunnel: 6ff42ae2-765d-4adf-8112-31c55c1551ef +credentials-file: /root/.cloudflared/6ff42ae2-765d-4adf-8112-31c55c1551ef.json + +ingress: + # Example of a request over TCP: + - hostname: example.com + service: tcp://localhost:8000 + # Example of an HTTP request over a Unix socket: + - hostname: staging.example.com + service: unix:/home/production/echo.sock + # Example of a request mapping to the Hello World test server: + - hostname: test.example.com + service: hello_world + # Example of a rule responding to traffic with an HTTP status: + - service: http_status:404 +``` + +### Origin configuration + +If you need to proxy traffic to multiple origins within one instance of `cloudflared`, you can define the way `cloudflared` sends requests to each service by specifying [configuration options](/tunnel/configuration/#origin-parameters) as part of your ingress rules. + +In the following example, the top-level configuration `connectTimeout: 30s` sets a 30-second connection timeout for all services within that instance of `cloudflared`. The ingress rule for `service: localhost:8002` then configures an exception to the top-level configuration by setting `connectTimeout` for that service at `10s`. The 30-second connection timeout still applies to all other services. + +```yml +tunnel: 6ff42ae2-765d-4adf-8112-31c55c1551ef +credentials-file: /root/.cloudflared/6ff42ae2-765d-4adf-8112-31c55c1551ef.json +originRequest: # Top-level configuration + connectTimeout: 30s + +ingress: + # The localhost:8000 service inherits all root-level configuration. + # In other words, it will use a connectTimeout of 30 seconds. + - hostname: example.com + service: localhost:8000 + - hostname: example2.com + service: localhost:8001 + # The localhost:8002 service overrides some root-level config. + - service: localhost:8002 + originRequest: + connectTimeout: 10s + disableChunkedEncoding: true + # Some built-in services such as `http_status` do not use any configuration. + # The service below will simply respond with HTTP 404. + - service: http_status:404 +``` + +### Validate ingress rules + +To validate the ingress rules in your configuration file, run: + +```sh +cloudflared tunnel ingress validate +``` + +This will ensure that the set of ingress rules specified in your config file is valid. + +### Test ingress rules + +To verify that `cloudflared` will proxy the right traffic to the right local service, use `cloudflared tunnel ingress rule`. This checks a URL against every rule, from first to last, and shows the first rule that matches. For example: + +```sh +cloudflared tunnel ingress rule https://foo.example.com +``` + +```sh output +Using rules from /usr/local/etc/cloudflared/config.yml +Matched rule #3 + hostname: *.example.com + service: https://localhost:8000 +``` + +## Update a configuration file + +When making changes to the configuration file for a given tunnel, we suggest relying on [`cloudflared` replicas](/tunnel/configuration/#replicas-and-high-availability) to propagate the new configuration with minimal downtime. + +1. Have a `cloudflared` instance running with the original version of the configuration file. +2. Start a `cloudflared` replica running with the updated version of the configuration file. +3. Wait for the replica to be fully running and usable. +4. Stop the first instance of `cloudflared`. + +Your `cloudflared` will now be running with the updated version of your configuration file. + +:::note[Traffic handling] + +When the first instance of `cloudflared` is stopped, long-lived HTTP requests (for example, Websocket) and TCP connections (for example, SSH) will be dropped. UDP flows will also be dropped, as they are modeled based on timeouts. When the new replica connects, it will handle all new traffic, including new HTTP requests, TCP connections, and UDP flows. + +::: diff --git a/src/content/docs/tunnel/advanced/local-management/create-local-tunnel.mdx b/src/content/docs/tunnel/advanced/local-management/create-local-tunnel.mdx new file mode 100644 index 000000000000000..ffeb729ccd6cc26 --- /dev/null +++ b/src/content/docs/tunnel/advanced/local-management/create-local-tunnel.mdx @@ -0,0 +1,88 @@ +--- +title: Create a locally-managed tunnel +pcx_content_type: how-to +sidebar: + order: 1 +--- + +Follow this step-by-step guide to create and run a locally-managed tunnel using the CLI. + +:::tip +If your server is behind a restrictive firewall, verify it can reach Cloudflare on port `7844` before proceeding. Refer to [Connectivity pre-checks](/tunnel/troubleshooting/#connectivity-pre-checks). +::: + +## Prerequisites + +- [Add a website to Cloudflare](/fundamentals/manage-domains/add-site/). +- [Change your domain nameservers to Cloudflare](/dns/zone-setups/full-setup/setup/). +- [Install `cloudflared`](/tunnel/downloads/) on your server. + +## 1. Authenticate `cloudflared` + +```sh +cloudflared tunnel login +``` + +This opens a browser window where you log in to your Cloudflare account and select your hostname. After authenticating, `cloudflared` generates a [cert.pem file](/tunnel/other-tunnel-types/local-management/local-tunnel-terms/#certpem) in the [default `cloudflared` directory](/tunnel/other-tunnel-types/local-management/local-tunnel-terms/#default-cloudflared-directory). + +## 2. Create a tunnel + +```sh +cloudflared tunnel create +``` + +This creates a persistent relationship between the name you provide and a UUID, generates a [tunnel credentials file](/tunnel/other-tunnel-types/local-management/local-tunnel-terms/#credentials-file), and creates a subdomain at `.cfargotunnel.com`. + +Take note of the tunnel UUID and credentials file path from the output. + +Confirm the tunnel was created: + +```sh +cloudflared tunnel list +``` + +## 3. Create a configuration file + +In your `.cloudflared` directory, create a [`config.yml` file](/tunnel/other-tunnel-types/local-management/configuration-file/): + +```yml +url: http://localhost:8000 +tunnel: +credentials-file: /root/.cloudflared/.json +``` + +## 4. Route traffic to the tunnel + +Create a DNS CNAME record that points traffic to your tunnel: + +```sh +cloudflared tunnel route dns +``` + +## 5. Run the tunnel + +```sh +cloudflared tunnel run +``` + +If your configuration file has a custom name or is not in the `.cloudflared` directory, add the `--config` flag: + +```sh +cloudflared tunnel --config /path/your-config-file.yml run +``` + +:::note +`cloudflared` can install itself as a system service on Linux and Windows and as a launch agent on macOS. For more information, refer to [Run as a service](/tunnel/other-tunnel-types/local-management/as-a-service/). +::: + +## 6. Verify the tunnel + +```sh +cloudflared tunnel info +``` + +Your tunnel is now running. For routing options, refer to [Routing](/tunnel/routing/). To add identity-based access controls, refer to [Cloudflare Access integration](/tunnel/integrations/#cloudflare-access). + +:::note[Looking for private network routing?] +For WARP-to-tunnel private network access, refer to the [Cloudflare One Tunnel documentation](/cloudflare-one/networks/connectors/cloudflare-tunnel/). +::: diff --git a/src/content/docs/tunnel/advanced/local-management/index.mdx b/src/content/docs/tunnel/advanced/local-management/index.mdx new file mode 100644 index 000000000000000..8220539e8b52ea6 --- /dev/null +++ b/src/content/docs/tunnel/advanced/local-management/index.mdx @@ -0,0 +1,14 @@ +--- +pcx_content_type: navigation +title: Locally-managed tunnels +sidebar: + order: 1 +--- + +import { DirectoryListing } from "~/components"; + +Cloudflare recommends creating a [remotely-managed tunnel](/tunnel/setup/) for most use cases. Remotely-managed tunnels store their configuration on Cloudflare, which allows you to manage the tunnel from any machine using the dashboard, API, or Terraform. + +As an alternative workflow, you can create a locally-managed tunnel by running `cloudflared tunnel create ` on the command line. Tunnel configuration is stored in your local [cloudflared directory](#default-cloudflared-directory). Locally-managed tunnels are intended for specific scenarios such as local development, testing, or legacy configurations. + + diff --git a/src/content/docs/tunnel/advanced/local-management/local-tunnel-terms.mdx b/src/content/docs/tunnel/advanced/local-management/local-tunnel-terms.mdx new file mode 100644 index 000000000000000..ad3a0bdfbffed91 --- /dev/null +++ b/src/content/docs/tunnel/advanced/local-management/local-tunnel-terms.mdx @@ -0,0 +1,35 @@ +--- +pcx_content_type: reference +title: Useful terms +sidebar: + order: 10 +--- + +This page contains terminology specific to locally-managed Cloudflare Tunnels. For general Tunnel terminology, refer to the [Get started section](/tunnel/faq/). + +## Default `cloudflared` directory + +`cloudflared` uses a default directory when storing credentials files for your tunnels, as well as the `cert.pem` file it generates when you run `cloudflared login`. The default directory is also where `cloudflared` will look for a [configuration file](#configuration-file) if no other file path is specified when running a tunnel. + +| OS | Path to default directory | +| --------------------------- | -------------------------------------------------------------------------------------- | +| Windows | `%USERPROFILE%\.cloudflared` | +| macOS and Unix-like systems | `~/.cloudflared`, `/etc/cloudflared`, and `/usr/local/etc/cloudflared`, in this order. | + +## Configuration file + +This is a YAML file that functions as the operating manual for `cloudflared`. `cloudflared` will automatically look for the configuration file in the [default `cloudflared` directory](#default-cloudflared-directory), but you can store your configuration file in any directory. It is recommended to always specify the file path for your configuration file whenever you reference it. By creating a configuration file, you can have fine-grained control over how their instance of `cloudflared` will operate. This includes operations like what you want `cloudflared` to do with traffic (for example, proxy websockets to port `xxxx` or SSH to port `yyyy`), where `cloudflared` should search for authorization (credentials file, tunnel token), and what mode it should run in (for example, [`warp-routing`](/cloudflare-one/networks/connectors/cloudflare-tunnel/private-net/)). In the absence of a configuration file, cloudflared will proxy outbound traffic through port `8080`. For more information on how to create, store, and structure a configuration file, refer to the [dedicated instructions](/tunnel/other-tunnel-types/local-management/configuration-file/). + +## Cert.pem + +This is the certificate file issued by Cloudflare when you run `cloudflared tunnel login`. This file uses a certificate to authenticate your instance of `cloudflared` and it is required when you create new tunnels, delete existing tunnels, change DNS records, or configure tunnel routing from cloudflared. This file is not required to perform actions such as running an existing tunnel or managing tunnel routing from the Cloudflare dashboard. Refer to the [Tunnel permissions page](/tunnel/other-tunnel-types/local-management/tunnel-permissions/) for more details on when this file is needed. + +The `cert.pem` origin certificate is valid for at least 10 years, and the service token it contains is valid until revoked. + +## Credentials file + +This file is created when you run `cloudflared tunnel create `. It stores your tunnel's credentials in JSON format, and is unique to each tunnel. This file functions as a token authenticating the tunnel it is associated with. Refer to the [Tunnel permissions page](/tunnel/other-tunnel-types/local-management/tunnel-permissions/) for more details on when this file is needed. + +## Ingress rule + +Ingress rules let you specify which local services traffic should be proxied to. If a rule does not specify a path, all paths will be matched. Ingress rules can be listed in your [configuration file](/tunnel/other-tunnel-types/local-management/configuration-file/) or when running `cloudflared tunnel ingress`. diff --git a/src/content/docs/tunnel/advanced/local-management/tunnel-permissions.mdx b/src/content/docs/tunnel/advanced/local-management/tunnel-permissions.mdx new file mode 100644 index 000000000000000..9a70f3101c89a47 --- /dev/null +++ b/src/content/docs/tunnel/advanced/local-management/tunnel-permissions.mdx @@ -0,0 +1,34 @@ +--- +pcx_content_type: reference +title: Tunnel permissions +sidebar: + order: 8 +--- + +import { Render } from "~/components"; + +Tunnel permissions determine who can run and manage a Cloudflare Tunnel. Two files control permissions for a locally-managed tunnel: + +- **An account certificate** (`cert.pem`) is issued for a Cloudflare account when you login to `cloudflared`. Make sure you are intentional about the locations and machines you store this certificate on, as this certificate allows users to create, delete, and manage all tunnels for the account. +- **A tunnel credentials file** (`.json`) is issued for a tunnel when you create the tunnel. The credentials file only allows the user to run that specific tunnel, and do nothing else. Hence, as an admin, you can share tunnel credentials with users who will run the tunnel. + +Refer to the table below for a comparison between the two files and the purposes for which they are intended. + +| | Account certificate | Tunnel credential | +| ----------------------- | -------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------- | +| **File name** | `cert.pem` | `.json` | +| **Purpose** | Authenticates your instance of `cloudflared` against your Cloudflare account | Authenticates the tunnel it is associated with | +| **Scope** | Account-wide | Tunnel-specific | +| **File type** | `.pem` | `.json` | +| **Stored in** | [Default directory](/tunnel/faq/#default-cloudflared-directory) | [Default directory](/tunnel/faq/#default-cloudflared-directory) | +| **Issued when running** | `cloudflared tunnel login` | `cloudflared tunnel create ` | +| **Valid for** | At least 10 years, and the service token it contains is valid until revoked | Does not expire | +| **Needed to** | Manage tunnels (for example, create, route, delete and list tunnels) | Run a tunnel. Create a config file. | + +## Tunnel ownership + +Tunnel ownership is bound to the Cloudflare account for which the `cert.pem` file was issued upon authenticating `cloudflared`. If a user in a Cloudflare account creates a tunnel, any other user in the same account who has access to the `cert.pem` file for the account can delete, list, or otherwise manage tunnels within it. + +## Account-scoped roles + + diff --git a/src/content/docs/tunnel/advanced/local-management/tunnel-useful-commands.mdx b/src/content/docs/tunnel/advanced/local-management/tunnel-useful-commands.mdx new file mode 100644 index 000000000000000..9a99a94ef1e5623 --- /dev/null +++ b/src/content/docs/tunnel/advanced/local-management/tunnel-useful-commands.mdx @@ -0,0 +1,37 @@ +--- +pcx_content_type: reference +title: Useful commands +sidebar: + order: 6 +--- + +This page lists the most commonly used commands for managing local tunnels. + +To view all CLI commands, refer to the CLI help text in your terminal. For example, to view all options for the `cloudflared tunnel` subcommand, type `cloudflared tunnel help`. + +## Manage tunnels + +| Command | Description | +| ------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| `cloudflared tunnel login` | Prompts a browser window where you can authenticate your tunnel to your Cloudflare account. | +| `cloudflared tunnel list` | Displays all active tunnels, their creation time, and associated connections. Use the `-d` flag to include deleted tunnels. | +| `cloudflared tunnel create ` | Creates a tunnel, registers it with the Cloudflare edge, and generates a credential file to run this tunnel. | +| `cloudflared tunnel route dns ` | Creates a DNS CNAME record that points to the tunnel. | +| `cloudflared tunnel --config path/config.yaml run ` | Runs a tunnel, creating highly available connections between your server and the Cloudflare edge. | +| `cloudflared tunnel info ` | Displays details about the active connectors for a given tunnel. | +| `cloudflared tunnel cleanup ` | Deletes connections for tunnels with the given UUIDs or names. This is useful if `cloudflared` was not shut down gracefully (for example, if a `kill` command was issued). | +| `cloudflared tunnel cleanup --connector-id ` | Disconnects and deletes a [cloudflared replica](/tunnel/configuration/#replicas-and-high-availability) with the given connector ID. | +| `cloudflared tunnel delete ` | Deletes tunnels with the given name or UUID. A tunnel cannot be deleted if it has active connections. Use the `-f` flag to delete unconditionally. | +| `cloudflared tail ` | Start a session to livestream logs from a specific tunnel. For more information, refer to [Tunnel logs](/tunnel/monitoring/#logs). | + +:::note +For private network routing commands (`tunnel route ip`, `tunnel vnet`), refer to the [Cloudflare One Tunnel documentation](/cloudflare-one/networks/connectors/cloudflare-tunnel/). +::: + +## Manage `cloudflared` + +| Command | Description | +| --------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| `cloudflared update` | Looks for a new version on the official download server. If a new version exists, updates the agent binary and quits. For more information, refer to [Update cloudflared](/tunnel/downloads/update-cloudflared/). | +| `cloudflared version` | Prints the `cloudflared` version number and build date. | +| `cloudflared help` | Shows a list of all top-level commands for `cloudflared`. | diff --git a/src/content/docs/tunnel/advanced/origin-parameters.mdx b/src/content/docs/tunnel/advanced/origin-parameters.mdx new file mode 100644 index 000000000000000..8510441689badaa --- /dev/null +++ b/src/content/docs/tunnel/advanced/origin-parameters.mdx @@ -0,0 +1,20 @@ +--- +pcx_content_type: reference +title: Origin parameters +sidebar: + order: 3 +--- + +import { Render } from "~/components"; + + diff --git a/src/content/docs/tunnel/advanced/run-parameters.mdx b/src/content/docs/tunnel/advanced/run-parameters.mdx new file mode 100644 index 000000000000000..8a155428c3341c2 --- /dev/null +++ b/src/content/docs/tunnel/advanced/run-parameters.mdx @@ -0,0 +1,24 @@ +--- +pcx_content_type: reference +title: Run parameters +sidebar: + order: 2 +--- + +import { Render } from "~/components"; + + diff --git a/src/content/docs/tunnel/changelog.mdx b/src/content/docs/tunnel/changelog.mdx new file mode 100644 index 000000000000000..b584cefca59d1c8 --- /dev/null +++ b/src/content/docs/tunnel/changelog.mdx @@ -0,0 +1,16 @@ +--- +pcx_content_type: changelog +title: Changelog +sidebar: + order: 11 +description: Review recent changes to Cloudflare Tunnel. +--- + +import { ProductChangelog } from "~/components"; + +{/* C{Cloudflare
Load Balancer} + C -- Tunnel 1 --> cf1 + C -- Tunnel 2 --> cf2 + subgraph F[Data center 2] + cf2[cloudflared] + S3[App server] + S4[App server] + cf2-->S3 + cf2-->S4 + end + subgraph E[Data center 1] + cf1[cloudflared] + S1[App server] + S2[App server] + cf1-->S1 + cf1-->S2 + end +``` + +### Replicas versus load balancers + +Running multiple `cloudflared` [replicas](/tunnel/configuration/#replicas-and-high-availability) on the same tunnel UUID provides basic redundancy — if one host fails, other replicas continue serving traffic. However, the load balancer treats all replicas of the same tunnel UUID as a single endpoint. + +For granular traffic steering and [session affinity](/load-balancing/understand-basics/session-affinity/), connect each host using a different tunnel UUID so the load balancer can address them independently. + +### Add a tunnel to a load balancer pool + +:::note[Prerequisites] +A Cloudflare Tunnel with at least one [published application route](/tunnel/setup/#publish-an-application). +::: + + **Tunnels**" + }} +/> + +
+ + + +
+ +
+ + + +
+ +## Cloudflare settings + + diff --git a/src/content/docs/tunnel/setup.mdx b/src/content/docs/tunnel/setup.mdx new file mode 100644 index 000000000000000..d6295a5589cac5b --- /dev/null +++ b/src/content/docs/tunnel/setup.mdx @@ -0,0 +1,185 @@ +--- +title: Setup +pcx_content_type: get-started +sidebar: + order: 2 +head: + - tag: title + content: Set up Cloudflare Tunnel +description: Create your first Cloudflare Tunnel and publish an application in under 5 minutes. +--- + +import { + DashButton, + Render, + Stream, + Tabs, + TabItem, + APIRequest, +} from "~/components"; + +Create a Cloudflare Tunnel and publish your first application in under 5 minutes. + +## Prerequisites + +- A [Cloudflare account](https://dash.cloudflare.com/sign-up) +- A [domain on Cloudflare](/fundamentals/manage-domains/add-site/) (required to publish applications) +- A server or VM with internet access where you will install `cloudflared` + +:::tip +If your server is behind a restrictive firewall, verify it can reach Cloudflare on port `7844` before proceeding. Refer to [Connectivity pre-checks](/tunnel/troubleshooting/#connectivity-pre-checks). +::: + +## Create a tunnel + +To create a new Cloudflare Tunnel: + + + + + + +1. In the [Cloudflare dashboard](https://dash.cloudflare.com/), go to **Networking** > **Tunnels**. + + +2. Select **Create Tunnel**. + +3. Enter a name for your tunnel (for example, `production-web` or `staging-api`). + +4. Select **Create Tunnel**. + +5. Under **Setup Environment**, select the operating system and architecture of your server. + +6. Copy the install commands shown under **Install and Run** and run them in a terminal on your server. + +7. Once the tunnel connects, select **Continue**. + +Your tunnel should appear on the **Tunnels** page with a `Healthy` status. + + + + +1. [Create an API token](/fundamentals/api/get-started/create-token/) with the following permissions: + + | Type | Item | Permission | + | ------- | ----------------- | ---------- | + | Account | Cloudflare Tunnel | Edit | + | Zone | DNS | Edit | + +2. Create a tunnel: + + + +3. Copy the `id` and `token` values from the response. You will need them to configure and run the tunnel. + + + + +## Publish an application + +To make an application accessible from the Internet, add a published application route to your tunnel. The tunnel route maps a public hostname to a local service. + + + + +1. In the [Cloudflare dashboard](https://dash.cloudflare.com/), go to **Networking** > **Tunnels** and select your tunnel. + +2. Under **Routes**, select **Add route**. + +3. Select **Published application**. + +4. Under **Hostname**, enter a subdomain and select a domain from the drop-down menu. + +5. For **Service URL**, enter the local address and port of your application. + + For example, if your web server runs on the same machine as `cloudflared`: + - HTTP on port `80`: `http://localhost:80` + - HTTPS on port `443`: `https://localhost:443` + + If your web server runs on a different machine: `http://192.0.2.1:80` + +6. Select **Add route**. + + + + +1. Configure your tunnel's ingress rules: + + + + Your ingress rules must include a catch-all rule at the end. In this example, `cloudflared` will respond with a 404 status code when the request does not match any hostname. + +2. Create a DNS record for your application: + + .cfargotunnel.com", + }} + /> + +3. Install `cloudflared` on your server and run the tunnel using the `token` obtained in [Create a tunnel](/tunnel/setup/#create-a-tunnel): + + + + + + +Your application is now live at the hostname you configured. Cloudflare automatically proxies traffic through its network, applying CDN caching, WAF, and DDoS protection. + +:::note +Non-HTTP services (SSH, TCP, RDP) require `cloudflared` on the client side. Refer to the [protocols reference](/tunnel/routing/#supported-protocols) for details. +::: + +## Quick tunnels (development) + +For local development, you can instantly expose localhost without a Cloudflare account: + +```sh +cloudflared tunnel --url http://localhost:8080 +``` + +This generates a random `trycloudflare.com` subdomain that proxies traffic to your local server. Quick tunnels are for testing only — they have a 200 concurrent request limit and do not support Server-Sent Events (SSE). + +For production use, [create a tunnel](#create-a-tunnel) instead. + +## Next steps + +- [Routing](/tunnel/routing/) — Configure DNS records, load balancers, and protocol support. +- [Configuration](/tunnel/configuration/) — Deploy replicas, manage tokens, and tune performance. +- [Integrations](/tunnel/integrations/) — Connect with Workers VPC, Load Balancing, and Access. +- [Monitoring](/tunnel/monitoring/) — View logs, metrics, and diagnostics. +- [Troubleshooting](/tunnel/troubleshooting/) — Connectivity pre-checks and common errors. +- [Deployment guides](/tunnel/deployment-guides/) — Deploy on Kubernetes, AWS, GCP, Terraform, and more. diff --git a/src/content/docs/tunnel/troubleshooting.mdx b/src/content/docs/tunnel/troubleshooting.mdx new file mode 100644 index 000000000000000..93a7bac82405a09 --- /dev/null +++ b/src/content/docs/tunnel/troubleshooting.mdx @@ -0,0 +1,99 @@ +--- +title: Troubleshooting +pcx_content_type: troubleshooting +sidebar: + order: 8 +--- + +import { Render, Tabs, TabItem } from "~/components"; + +Use this page to diagnose and resolve common issues with Cloudflare Tunnel. For tunnel health monitoring, logs, and metrics, refer to [Monitoring](/tunnel/monitoring/). + +## Connectivity pre-checks + +Before deploying a tunnel, validate that your environment can reach [Cloudflare Tunnel endpoints](/tunnel/configuration/#firewall-rules). Run these tests from the same host machine that will run `cloudflared`. + +### DNS resolution + +Cloudflare Tunnel requires outbound connectivity to `region1.v2.argotunnel.com` and `region2.v2.argotunnel.com` (or `us-region1` and `us-region2` for the [US region](/tunnel/configuration/#region)). + +Verify that your DNS resolver returns the expected IP addresses: + + + + +```sh +dig A region1.v2.argotunnel.com +``` + +```sh +dig A region2.v2.argotunnel.com +``` + +You should see IP addresses in the `198.41.192.x` and `198.41.200.x` ranges. + + + + +```sh +dig A us-region1.v2.argotunnel.com +``` + +```sh +dig A us-region2.v2.argotunnel.com +``` + +You should see IP addresses in the `198.41.218.x` and `198.41.219.x` ranges. + + + + +If you receive a `SERVFAIL`, `NXDOMAIN`, or empty answer, test against Cloudflare's public resolver: + +```sh +dig A region1.v2.argotunnel.com @1.1.1.1 +``` + +- **Only `1.1.1.1` works** — Your local DNS resolver is misconfigured or blocked. Configure the host to use `1.1.1.1`, or investigate with your system administrator. +- **Neither resolver works** — Your firewall may be blocking DNS queries (UDP port `53`). Check for firewall rules or contact your DNS provider. + +### Network connectivity + +After confirming DNS resolution, test whether your host can send packets to Cloudflare on port `7844`. Choose an IP from your `dig` output (for example, `198.41.192.167`). + +```sh +nc -uvz -w 3 198.41.192.167 7844 # UDP +nc -vz -w 3 198.41.192.167 7844 # TCP +``` + +| Result | Meaning | Action | +| ------------------------ | ------------------------------------------------------------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------- | +| Both UDP and TCP succeed | `cloudflared` can connect using `quic` (UDP) or `http2` (TCP). | Deploy the tunnel. | +| UDP succeeds, TCP fails | TCP on port `7844` is blocked. `cloudflared` can only use `quic`. | Allow TCP on port `7844`, or do not force `http2` in your [protocol](/tunnel/configuration/#protocol) configuration. | +| TCP succeeds, UDP fails | UDP on port `7844` is blocked. `cloudflared` can only use `http2`. | Allow UDP on port `7844`, or do not force `quic` in your [protocol](/tunnel/configuration/#protocol) configuration. | +| Both fail | Packets are being dropped between the host and Cloudflare. | Allow all traffic over port `7844` on the local network firewall. If this does not resolve the issue, troubleshoot with your ISP or service provider. | + +If DNS or network tests fail, the problem is likely in your local environment. Debug with your administrator, ISP, or cloud provider. + + + +## How do I contact support? + + \ No newline at end of file diff --git a/src/content/learning-paths/clientless-access.json b/src/content/learning-paths/clientless-access.json index 782a784ac1d29c4..59aa949705ea8dc 100644 --- a/src/content/learning-paths/clientless-access.json +++ b/src/content/learning-paths/clientless-access.json @@ -3,5 +3,5 @@ "path": "/learning-paths/clientless-access/concepts/", "description": "Learn how to set up clientless access to internal applications with Cloudflare Zero Trust.", "pcx_content_type": "learning-path", - "products": ["access", "cloudflare-tunnel", "browser-isolation"] + "products": ["access", "cloudflare-tunnel-sase", "browser-isolation"] } diff --git a/src/content/learning-paths/replace-vpn.json b/src/content/learning-paths/replace-vpn.json index 62cc34fb4920e38..6d1dfab70250e13 100644 --- a/src/content/learning-paths/replace-vpn.json +++ b/src/content/learning-paths/replace-vpn.json @@ -3,5 +3,5 @@ "path": "/learning-paths/replace-vpn/concepts/", "description": "Learn how to replace your VPN with Cloudflare Zero Trust.", "pcx_content_type": "learning-path", - "products": ["gateway", "cloudflare-tunnel", "zero-trust-warp"] + "products": ["gateway", "cloudflare-tunnel-sase", "zero-trust-warp"] } diff --git a/src/content/partials/cloudflare-one/tunnel/cloudflared-replicas-diagram.mdx b/src/content/partials/cloudflare-one/tunnel/cloudflared-replicas-diagram.mdx new file mode 100644 index 000000000000000..8e51e41f3ac6672 --- /dev/null +++ b/src/content/partials/cloudflare-one/tunnel/cloudflared-replicas-diagram.mdx @@ -0,0 +1,24 @@ +--- +{} + +--- + +```mermaid +graph LR + C((Cloudflare)) + subgraph E[Your network] + cf1["cloudflared
(Tunnel-1 replica)"] + cf2["cloudflared
(Tunnel-1 replica)"] + S1[Application] + cf1-->S1 + cf2-->S1 + end + C -- "Connections x 4
"--> cf1 + C --> cf1 + C --> cf1 + C --> cf1 + C -- Connections x 4--> cf2 + C --> cf2 + C --> cf2 + C --> cf2 +``` diff --git a/src/content/partials/cloudflare-one/tunnel/common-errors.mdx b/src/content/partials/cloudflare-one/tunnel/common-errors.mdx new file mode 100644 index 000000000000000..3d37f4991c739cd --- /dev/null +++ b/src/content/partials/cloudflare-one/tunnel/common-errors.mdx @@ -0,0 +1,204 @@ +--- +params: + - logsURL + - protocolURL + - configFileURL + - originServerNameURL + - caPoolURL + - noTLSVerifyURL + - ulimitsURL +--- + +import { Render } from "~/components"; + +## I see `cloudflared service is already installed`. + +If you see this error when installing a remotely-managed tunnel, ensure that no other `cloudflared` instances are running as a service on this machine. Only a single instance of `cloudflared` may run as a service on any given machine. Instead, add additional routes to your existing tunnel. Alternatively, you can run `sudo cloudflared service uninstall` to uninstall `cloudflared`. + +## I see `An A, AAAA, or CNAME record with that host already exists`. + +If you are unable to save your tunnel's public hostname, choose a different hostname or delete the existing DNS record. [Check the DNS records](/dns/manage-dns-records/how-to/create-dns-records/) for your domain from the [Cloudflare dashboard](https://dash.cloudflare.com). + +## Tunnel credentials file does not exist or is not a file. + +If you encounter the following error when running a tunnel, double check your `config.yml` file and ensure that the `credentials-file` points to the correct location. You may need to change `/root/` to your home directory. + +```sh +cloudflared tunnel run +``` + +```sh output +2021-06-04T06:21:16Z INF Starting tunnel tunnelID=928655cc-7f95-43f2-8539-2aba6cf3592d +Tunnel credentials file '/root/.cloudflared/928655cc-7f95-43f2-8539-2aba6cf3592d.json' doesn't exist or is not a file +``` + +## My tunnel fails to authenticate. + +To start using Cloudflare Tunnel, a super administrator in the Cloudflare account must first log in through `cloudflared login`. The client will launch a browser window and prompt the user to select a hostname in their Cloudflare account. Once selected, Cloudflare generates a certificate that consists of three components: + +- The public key of the origin certificate for that hostname +- The private key of the origin certificate for that domain +- A token that is unique to Cloudflare Tunnel + +Those three components are bundled into a single PEM file that is downloaded one time during that login flow. The host certificate is valid for the root domain and any subdomain one-level deep. Cloudflare uses that certificate file to authenticate `cloudflared` to create DNS records for your domain in Cloudflare. + +The third component, the token, consists of the zone ID (for the selected domain) and an API token scoped to the user who first authenticated with the login command. When user permissions change (if that user is removed from the account or becomes an admin of another account, for example), Cloudflare rolls the user's API key. However, the certificate file downloaded through `cloudflared` retains the older API key and can cause authentication failures. The user will need to login once more through `cloudflared` to regenerate the certificate. Alternatively, the administrator can create a dedicated service user to authenticate. + +## I see an error: x509: certificate signed by unknown authority. + +This means the origin is using a certificate that `cloudflared` does not trust. For example, you may get this error if you are using SSL/TLS inspection in a proxy between your server and Cloudflare. To resolve: + +- Add the certificate to the system certificate pool. +- Use the `--origin-ca-pool` flag and specify the path to the certificate. +- Use the `--no-tls-verify` flag to stop `cloudflared` checking the certificate for a trust chain. + +## I see an error 1033 when attempting to run a tunnel. + + + +For more information, refer to the [comprehensive list of Cloudflare 1xxx errors](/support/troubleshooting/http-status-codes/cloudflare-1xxx-errors/). + +## I see a 502 Bad Gateway error when connecting to an HTTP or HTTPS application through tunnel. + +A `502 Bad Gateway` error with `Unable to reach the origin service. The service may be down or it may not be responding to traffic from cloudflared` on a tunnel route means the tunnel itself is connected to the Cloudflare network, but `cloudflared` cannot reach the origin service defined in your ingress rule. Unlike [error 1033](#i-see-an-error-1033-when-attempting-to-run-a-tunnel), which indicates the tunnel is not connected to Cloudflare, a 502 error indicates the problem is between `cloudflared` and your local service. + +To identify the specific cause, review your Tunnel logs for `error`-level messages. Common causes include: + +#### Origin service is not running + +If the origin service has stopped or never started, `cloudflared` logs will show an error similar to: + +```txt +error="dial tcp [::1]:8080: connect: connection refused" +``` + +To resolve, verify the service is running and listening on the expected port: + +```sh +curl -v http://localhost:8080 +``` + +If the service is not running, start or restart it. You can confirm the service is listening by running `ss -tlnp | grep ` (Linux) or `lsof -iTCP -sTCP:LISTEN -nP | grep ` (macOS). + +#### Origin service URL uses the wrong protocol + +If the origin expects HTTPS but the tunnel route specifies `http://`, or vice versa, `cloudflared` logs will show an error similar to: + +```txt +error="net/http: HTTP/1.x transport connection broken: malformed HTTP response \"\x15\x03\x01\x00\x02\x02\"" +``` + +To resolve, update the service URL in your tunnel route to match the protocol your origin expects. For example, change `http://localhost:8080` to `https://localhost:8080`. If you are using a locally-managed tunnel, update your ingress rule in the configuration file. + +#### Origin service URL points to the wrong port + +If the port in your tunnel route does not match the port your service is listening on, `cloudflared` will log a `connection refused` error for that port. Double-check the service URL in your ingress rule and compare it against the port your application is bound to. + +#### Origin uses a certificate that `cloudflared` does not trust + +If the origin presents a TLS certificate that `cloudflared` cannot verify, the logs will show an error similar to: + +```txt +error="x509: certificate is valid for example.com, not localhost" +``` + +This commonly occurs when the origin uses a self-signed certificate or when an SSL/TLS inspection proxy sits between `cloudflared` and the origin. + +To resolve, use one of the following approaches: + +- Set `originServerName` to the hostname on the origin certificate in your tunnel route. If you are using a locally-managed tunnel, here is an example of a configuration file: + + ```yml + ingress: + - hostname: app.example.com + service: https://localhost:443 + originRequest: + originServerName: app.example.com + ``` + +- Provide the CA certificate using `caPool`: + + ```yml + ingress: + - hostname: app.example.com + service: https://localhost:443 + originRequest: + caPool: /path/to/ca-cert.pem + ``` + +- As a last resort, disable TLS verification with `noTLSVerify`. This is not recommended for production environments. + + ```yml + ingress: + - hostname: app.example.com + service: https://localhost:443 + originRequest: + noTLSVerify: true + ``` + +## I see `ERR_TOO_MANY_REDIRECTS` when attempting to connect to an Access self-hosted app. + +This error occurs when `cloudflared` does not recognize the SSL/TLS certificate presented by your origin. To resolve the issue, set the origin server name parameter to the hostname on your origin certificate. Here is an example of a locally-managed tunnel configuration: + +```txt +ingress: + - hostname: test.example.com + service: https://localhost:443 + originRequest: + originServerName: test.example.com +``` + +## `cloudflared access` shows an error `websocket: bad handshake`. + +This means that your `cloudflared access` client is unable to reach your `cloudflared tunnel` origin. To diagnose this, look at the `cloudflared tunnel` logs. A common root cause is that the `cloudflared tunnel` is unable to proxy to your origin (for example, because the ingress is misconfigured, the origin is down, or the origin HTTPS certificate cannot be validated by `cloudflared tunnel`). If `cloudflared tunnel` has no logs, it means Cloudflare's network is not able to route the websocket traffic to it. + +There are several possible root causes behind this error: + +- Your `cloudflared tunnel` is either not running or not connected to Cloudflare's network. +- WebSockets are not [enabled](/network/websockets/#enable-websockets). +- Your Cloudflare account has Universal SSL enabled but your SSL/TLS encryption mode is set to **Off (not secure)**. To resolve, go to **SSL/TLS** > **Overview** in the Cloudflare dashboard and set your SSL/TLS encryption mode to **Flexible**, **Full**, or **Full (strict)**. +- Your requests are blocked by [Super Bot Fight Mode](/bots/get-started/super-bot-fight-mode/). To resolve, make sure you set **Definitely automated** to _Allow_ in the bot fight mode settings. +- Your SSH or RDP Access application has the [Binding Cookie](/cloudflare-one/access-controls/applications/http-apps/authorization-cookie/#binding-cookie) enabled. To disable the cookie, go to **Access controls** > **Applications** and edit the application settings. +- One or more [Workers routes](/workers/configuration/routing/routes/) are overlapping with the tunnel hostname, and the Workers do not properly handle the traffic. To resolve, either exclude your tunnel from the Worker route by not defining a route that includes the tunnel's hostname, or update your Worker to only handle specific paths and forward all other requests to the origin (for example, by using `return fetch(req)`). + +## Tunnel connections fail with SSL error. + +If `cloudflared` returns error `error="remote error: tls: handshake failure"`, check to make sure the hostname in question is covered by a SSL certificate. If using a multi-level subdomain, an [advanced certificate](/ssl/edge-certificates/advanced-certificate-manager/) may be required as the Universal SSL will not cover more than one level of subdomain. This may surface in the browser as `ERR_SSL_VERSION_OR_CIPHER_MISMATCH`. + +## Tunnel connections fail with `Too many open files` error. + +If your Cloudflare Tunnel logs return a `socket: too many open files` error, it means that `cloudflared` has exhausted the open files limit on your machine. The maximum number of open files, or file descriptors, is an operating system setting that determines how many files a process is allowed to open. To increase the open file limit, you will need to configure ulimit settings on the machine running `cloudflared`. + +## I see `failed to sufficiently increase receive buffer size` in my cloudflared logs. + +This buffer size increase is reported by the [quic-go library](https://github.com/quic-go/quic-go) leveraged by [cloudflared](https://github.com/cloudflare/cloudflared). You can learn more about the log message in the [quic-go repository](https://github.com/quic-go/quic-go/wiki/UDP-Buffer-Sizes). This log message is generally not impactful and can be safely ignored when troubleshooting. However, if you have deployed `cloudflared` within a unique, high-bandwidth environment then buffer size can be manually overridden for testing purposes. + +To set the maximum receive buffer size on Linux: + +1. Create a new file under `/etc/sysctl.d/`: + + ```sh + sudo vi 98-core-rmem-max.conf + ``` + +2. In the file, define the desired buffer size: + + ```txt + net.core.rmem_max=2500000 + ``` + +3. Reboot the host machine running `cloudflared`. + +4. To validate that these changes have taken effect, use the `grep` command: + + ```sh + sudo sysctl -a | grep net.core.rmem_max + ``` + + ```sh output + net.core.rmem_max = 2500000 + ``` + +## Cloudflare Tunnel is buffering my streaming response instead of streaming it live. + +Proxied traffic through Cloudflare Tunnel is buffered by default unless the origin server includes the `Content-Type: text/event-stream` response header. This header tells `cloudflared` to stream data as it arrives instead of buffering the entire response. diff --git a/src/content/partials/cloudflare-one/tunnel/common-errors/502-bad-gateway.mdx b/src/content/partials/cloudflare-one/tunnel/common-errors/502-bad-gateway.mdx new file mode 100644 index 000000000000000..750db57a4d52155 --- /dev/null +++ b/src/content/partials/cloudflare-one/tunnel/common-errors/502-bad-gateway.mdx @@ -0,0 +1,85 @@ +--- +params: + - logsURL + - protocolURL + - configFileURL + - originServerNameURL + - caPoolURL + - noTLSVerifyURL +--- + +A `502 Bad Gateway` error with `Unable to reach the origin service. The service may be down or it may not be responding to traffic from cloudflared` on a tunnel route means the tunnel itself is connected to the Cloudflare network, but `cloudflared` cannot reach the origin service defined in your ingress rule. Unlike [error 1033](#i-see-an-error-1033-when-attempting-to-run-a-tunnel), which indicates the tunnel is not connected to Cloudflare, a 502 error indicates the problem is between `cloudflared` and your local service. + +To identify the specific cause, review your Tunnel logs for `error`-level messages. Common causes include: + +#### Origin service is not running + +If the origin service has stopped or never started, `cloudflared` logs will show an error similar to: + +```txt +error="dial tcp [::1]:8080: connect: connection refused" +``` + +To resolve, verify the service is running and listening on the expected port: + +```sh +curl -v http://localhost:8080 +``` + +If the service is not running, start or restart it. You can confirm the service is listening by running `ss -tlnp | grep ` (Linux) or `lsof -iTCP -sTCP:LISTEN -nP | grep ` (macOS). + +#### Origin service URL uses the wrong protocol + +If the origin expects HTTPS but the tunnel route specifies `http://`, or vice versa, `cloudflared` logs will show an error similar to: + +```txt +error="net/http: HTTP/1.x transport connection broken: malformed HTTP response \"\x15\x03\x01\x00\x02\x02\"" +``` + +To resolve, update the service URL in your tunnel route to match the protocol your origin expects. For example, change `http://localhost:8080` to `https://localhost:8080`. If you are using a locally-managed tunnel, update your ingress rule in the configuration file. + +#### Origin service URL points to the wrong port + +If the port in your tunnel route does not match the port your service is listening on, `cloudflared` will log a `connection refused` error for that port. Double-check the service URL in your ingress rule and compare it against the port your application is bound to. + +#### Origin uses a certificate that `cloudflared` does not trust + +If the origin presents a TLS certificate that `cloudflared` cannot verify, the logs will show an error similar to: + +```txt +error="x509: certificate is valid for example.com, not localhost" +``` + +This commonly occurs when the origin uses a self-signed certificate or when an SSL/TLS inspection proxy sits between `cloudflared` and the origin. + +To resolve, use one of the following approaches: + +- Set `originServerName` to the hostname on the origin certificate in your tunnel route. If you are using a locally-managed tunnel, here is an example of a configuration file: + + ```yml + ingress: + - hostname: app.example.com + service: https://localhost:443 + originRequest: + originServerName: app.example.com + ``` + +- Provide the CA certificate using `caPool`: + + ```yml + ingress: + - hostname: app.example.com + service: https://localhost:443 + originRequest: + caPool: /path/to/ca-cert.pem + ``` + +- As a last resort, disable TLS verification with `noTLSVerify`. This is not recommended for production environments. + + ```yml + ingress: + - hostname: app.example.com + service: https://localhost:443 + originRequest: + noTLSVerify: true + ``` diff --git a/src/content/partials/cloudflare-one/tunnel/common-errors/credentials-file-not-found.mdx b/src/content/partials/cloudflare-one/tunnel/common-errors/credentials-file-not-found.mdx new file mode 100644 index 000000000000000..91fb4ddaea1b1ea --- /dev/null +++ b/src/content/partials/cloudflare-one/tunnel/common-errors/credentials-file-not-found.mdx @@ -0,0 +1,14 @@ +--- +{} +--- + +If you encounter the following error when running a tunnel, double check your `config.yml` file and ensure that the `credentials-file` points to the correct location. You may need to change `/root/` to your home directory. + +```sh +cloudflared tunnel run +``` + +```sh output +2021-06-04T06:21:16Z INF Starting tunnel tunnelID=928655cc-7f95-43f2-8539-2aba6cf3592d +Tunnel credentials file '/root/.cloudflared/928655cc-7f95-43f2-8539-2aba6cf3592d.json' doesn't exist or is not a file +``` diff --git a/src/content/partials/cloudflare-one/tunnel/common-errors/dns-record-already-exists.mdx b/src/content/partials/cloudflare-one/tunnel/common-errors/dns-record-already-exists.mdx new file mode 100644 index 000000000000000..b9695021ad9f267 --- /dev/null +++ b/src/content/partials/cloudflare-one/tunnel/common-errors/dns-record-already-exists.mdx @@ -0,0 +1,5 @@ +--- +{} +--- + +If you are unable to save your tunnel's public hostname, choose a different hostname or delete the existing DNS record. [Check the DNS records](/dns/manage-dns-records/how-to/create-dns-records/) for your domain from the [Cloudflare dashboard](https://dash.cloudflare.com). diff --git a/src/content/partials/cloudflare-one/tunnel/common-errors/err-too-many-redirects.mdx b/src/content/partials/cloudflare-one/tunnel/common-errors/err-too-many-redirects.mdx new file mode 100644 index 000000000000000..e8d1242efcffbfc --- /dev/null +++ b/src/content/partials/cloudflare-one/tunnel/common-errors/err-too-many-redirects.mdx @@ -0,0 +1,14 @@ +--- +params: + - originServerNameURL +--- + +This error occurs when `cloudflared` does not recognize the SSL/TLS certificate presented by your origin. To resolve the issue, set the origin server name parameter to the hostname on your origin certificate. Here is an example of a locally-managed tunnel configuration: + +```txt +ingress: + - hostname: test.example.com + service: https://localhost:443 + originRequest: + originServerName: test.example.com +``` diff --git a/src/content/partials/cloudflare-one/tunnel/common-errors/error-1033.mdx b/src/content/partials/cloudflare-one/tunnel/common-errors/error-1033.mdx new file mode 100644 index 000000000000000..432974cdcaa1755 --- /dev/null +++ b/src/content/partials/cloudflare-one/tunnel/common-errors/error-1033.mdx @@ -0,0 +1,9 @@ +--- +{} +--- + +import { Render } from "~/components"; + + + +For more information, refer to the [comprehensive list of Cloudflare 1xxx errors](/support/troubleshooting/http-status-codes/cloudflare-1xxx-errors/). diff --git a/src/content/partials/cloudflare-one/tunnel/common-errors/receive-buffer-size.mdx b/src/content/partials/cloudflare-one/tunnel/common-errors/receive-buffer-size.mdx new file mode 100644 index 000000000000000..ab051ac80f9bdf9 --- /dev/null +++ b/src/content/partials/cloudflare-one/tunnel/common-errors/receive-buffer-size.mdx @@ -0,0 +1,31 @@ +--- +{} +--- + +This buffer size increase is reported by the [quic-go library](https://github.com/quic-go/quic-go) leveraged by [cloudflared](https://github.com/cloudflare/cloudflared). You can learn more about the log message in the [quic-go repository](https://github.com/quic-go/quic-go/wiki/UDP-Buffer-Sizes). This log message is generally not impactful and can be safely ignored when troubleshooting. However, if you have deployed `cloudflared` within a unique, high-bandwidth environment then buffer size can be manually overridden for testing purposes. + +To set the maximum receive buffer size on Linux: + +1. Create a new file under `/etc/sysctl.d/`: + +```sh +sudo vi 98-core-rmem-max.conf +``` + +2. In the file, define the desired buffer size: + +```txt +net.core.rmem_max=2500000 +``` + +3. Reboot the host machine running `cloudflared`. + +4. To validate that these changes have taken effect, use the `grep` command: + +```sh +sudo sysctl -a | grep net.core.rmem_max +``` + +```sh output +net.core.rmem_max = 2500000 +``` diff --git a/src/content/partials/cloudflare-one/tunnel/common-errors/service-already-installed.mdx b/src/content/partials/cloudflare-one/tunnel/common-errors/service-already-installed.mdx new file mode 100644 index 000000000000000..2d81832c800ffc7 --- /dev/null +++ b/src/content/partials/cloudflare-one/tunnel/common-errors/service-already-installed.mdx @@ -0,0 +1,5 @@ +--- +{} +--- + +If you see this error when installing a remotely-managed tunnel, ensure that no other `cloudflared` instances are running as a service on this machine. Only a single instance of `cloudflared` may run as a service on any given machine. Instead, add additional routes to your existing tunnel. Alternatively, you can run `sudo cloudflared service uninstall` to uninstall `cloudflared`. diff --git a/src/content/partials/cloudflare-one/tunnel/common-errors/ssl-handshake-failure.mdx b/src/content/partials/cloudflare-one/tunnel/common-errors/ssl-handshake-failure.mdx new file mode 100644 index 000000000000000..54bb37642a94c3d --- /dev/null +++ b/src/content/partials/cloudflare-one/tunnel/common-errors/ssl-handshake-failure.mdx @@ -0,0 +1,5 @@ +--- +{} +--- + +If `cloudflared` returns error `error="remote error: tls: handshake failure"`, check to make sure the hostname in question is covered by a SSL certificate. If using a multi-level subdomain, an [advanced certificate](/ssl/edge-certificates/advanced-certificate-manager/) may be required as the Universal SSL will not cover more than one level of subdomain. This may surface in the browser as `ERR_SSL_VERSION_OR_CIPHER_MISMATCH`. diff --git a/src/content/partials/cloudflare-one/tunnel/common-errors/streaming-responses-buffered.mdx b/src/content/partials/cloudflare-one/tunnel/common-errors/streaming-responses-buffered.mdx new file mode 100644 index 000000000000000..94fd62a5494fea8 --- /dev/null +++ b/src/content/partials/cloudflare-one/tunnel/common-errors/streaming-responses-buffered.mdx @@ -0,0 +1,5 @@ +--- +{} +--- + +Proxied traffic through Cloudflare Tunnel is buffered by default unless the origin server includes the `Content-Type: text/event-stream` response header. This header tells `cloudflared` to stream data as it arrives instead of buffering the entire response. diff --git a/src/content/partials/cloudflare-one/tunnel/common-errors/too-many-open-files.mdx b/src/content/partials/cloudflare-one/tunnel/common-errors/too-many-open-files.mdx new file mode 100644 index 000000000000000..9e63bec2ef0bdac --- /dev/null +++ b/src/content/partials/cloudflare-one/tunnel/common-errors/too-many-open-files.mdx @@ -0,0 +1,7 @@ +--- +params: + - logsURL + - ulimitsURL +--- + +If your Cloudflare Tunnel logs return a `socket: too many open files` error, it means that `cloudflared` has exhausted the open files limit on your machine. The maximum number of open files, or file descriptors, is an operating system setting that determines how many files a process is allowed to open. To increase the open file limit, you will need to configure ulimit settings on the machine running `cloudflared`. diff --git a/src/content/partials/cloudflare-one/tunnel/common-errors/tunnel-fails-to-authenticate.mdx b/src/content/partials/cloudflare-one/tunnel/common-errors/tunnel-fails-to-authenticate.mdx new file mode 100644 index 000000000000000..3c9886fd410f158 --- /dev/null +++ b/src/content/partials/cloudflare-one/tunnel/common-errors/tunnel-fails-to-authenticate.mdx @@ -0,0 +1,13 @@ +--- +{} +--- + +To start using Cloudflare Tunnel, a super administrator in the Cloudflare account must first log in through `cloudflared login`. The client will launch a browser window and prompt the user to select a hostname in their Cloudflare account. Once selected, Cloudflare generates a certificate that consists of three components: + +- The public key of the origin certificate for that hostname +- The private key of the origin certificate for that domain +- A token that is unique to Cloudflare Tunnel + +Those three components are bundled into a single PEM file that is downloaded one time during that login flow. The host certificate is valid for the root domain and any subdomain one-level deep. Cloudflare uses that certificate file to authenticate `cloudflared` to create DNS records for your domain in Cloudflare. + +The third component, the token, consists of the zone ID (for the selected domain) and an API token scoped to the user who first authenticated with the login command. When user permissions change (if that user is removed from the account or becomes an admin of another account, for example), Cloudflare rolls the user's API key. However, the certificate file downloaded through `cloudflared` retains the older API key and can cause authentication failures. The user will need to login once more through `cloudflared` to regenerate the certificate. Alternatively, the administrator can create a dedicated service user to authenticate. diff --git a/src/content/partials/cloudflare-one/tunnel/common-errors/websocket-bad-handshake.mdx b/src/content/partials/cloudflare-one/tunnel/common-errors/websocket-bad-handshake.mdx new file mode 100644 index 000000000000000..ffb2fdc7f030016 --- /dev/null +++ b/src/content/partials/cloudflare-one/tunnel/common-errors/websocket-bad-handshake.mdx @@ -0,0 +1,14 @@ +--- +{} +--- + +This means that your `cloudflared access` client is unable to reach your `cloudflared tunnel` origin. To diagnose this, look at the `cloudflared tunnel` logs. A common root cause is that the `cloudflared tunnel` is unable to proxy to your origin (for example, because the ingress is misconfigured, the origin is down, or the origin HTTPS certificate cannot be validated by `cloudflared tunnel`). If `cloudflared tunnel` has no logs, it means Cloudflare's network is not able to route the websocket traffic to it. + +There are several possible root causes behind this error: + +- Your `cloudflared tunnel` is either not running or not connected to Cloudflare's network. +- WebSockets are not [enabled](/network/websockets/#enable-websockets). +- Your Cloudflare account has Universal SSL enabled but your SSL/TLS encryption mode is set to **Off (not secure)**. To resolve, go to **SSL/TLS** > **Overview** in the Cloudflare dashboard and set your SSL/TLS encryption mode to **Flexible**, **Full**, or **Full (strict)**. +- Your requests are blocked by [Super Bot Fight Mode](/bots/get-started/super-bot-fight-mode/). To resolve, make sure you set **Definitely automated** to _Allow_ in the bot fight mode settings. +- Your SSH or RDP Access application has the [Binding Cookie](/cloudflare-one/access-controls/applications/http-apps/authorization-cookie/#binding-cookie) enabled. To disable the cookie, go to **Access controls** > **Applications** and edit the application settings. +- One or more [Workers routes](/workers/configuration/routing/routes/) are overlapping with the tunnel hostname, and the Workers do not properly handle the traffic. To resolve, either exclude your tunnel from the Worker route by not defining a route that includes the tunnel's hostname, or update your Worker to only handle specific paths and forward all other requests to the origin (for example, by using `return fetch(req)`). diff --git a/src/content/partials/cloudflare-one/tunnel/common-errors/x509-unknown-authority.mdx b/src/content/partials/cloudflare-one/tunnel/common-errors/x509-unknown-authority.mdx new file mode 100644 index 000000000000000..c752c59f374e493 --- /dev/null +++ b/src/content/partials/cloudflare-one/tunnel/common-errors/x509-unknown-authority.mdx @@ -0,0 +1,9 @@ +--- +{} +--- + +This means the origin is using a certificate that `cloudflared` does not trust. For example, you may get this error if you are using SSL/TLS inspection in a proxy between your server and Cloudflare. To resolve: + +- Add the certificate to the system certificate pool. +- Use the `--origin-ca-pool` flag and specify the path to the certificate. +- Use the `--no-tls-verify` flag to stop `cloudflared` checking the certificate for a trust chain. diff --git a/src/content/partials/cloudflare-one/tunnel/diag-docker.mdx b/src/content/partials/cloudflare-one/tunnel/diag-docker.mdx new file mode 100644 index 000000000000000..4f15318c29c1162 --- /dev/null +++ b/src/content/partials/cloudflare-one/tunnel/diag-docker.mdx @@ -0,0 +1,53 @@ +--- +params: + - metricsURL + - defaultMetricsURL +--- + +`cloudflared` reads diagnostic data from the tunnel metrics server. To get diagnostic logs, the metrics server must be exposed from the Docker container and reachable from the host machine. + +1. Determine the metrics server port for the `cloudflared` instance running in Docker. + +2. Ensure the container is deployed with port forwarding enabled. The diagnostic feature will request information from the Docker instance using local port `20241`, therefore you should forward port `20241` to the container port obtained in Step 1: + + ```sh + docker run -d -p 20241: docker.io/cloudflare/cloudflared tunnel ... + ``` + +3. Verify that you can reach the metrics server address from the Docker host environment: + + ```sh + curl localhost:20241/diag/tunnel + ``` + + This command should return a JSON: + + ```json + { + "tunnelID": "ef96b330-a7f5-4bce-a00e-827ce5be077f", + "connectorID": "d236670a-9f74-422f-adf1-030f5c5f0523", + "connections": [ + { "isConnected": true, "protocol": 1, "edgeAddress": "198.41.192.167"}, + {"isConnected": true, "protocol": 1, "edgeAddress": "198.41.200.113", "index": 1}, + {"isConnected": true, "protocol": 1, "edgeAddress": "198.41.192.47", "index": 2}, + {"isConnected": true, "protocol": 1, "edgeAddress": "198.41.200.73", "index": 3} + ], + "icmp_sources": ["192.168.1.243", "fe80::c59:bd4a:e815:ed6"] + } + ``` + +4. Run the diagnostic using the Docker container ID: + + ```sh + cloudflared tunnel diag --diag-container-id= + ``` + + Alternatively, you can specify the container's name instead of its ID: + + ```sh + cloudflared tunnel diag --diag-container-id= + ``` + + Running the diagnostic command with the container ID allows `cloudflared` to collect information from the Docker environment such as logs and container details. + +This command will output the status of each diagnostic task and place a `cloudflared-diag-YYYY-MM-DDThh-mm-ss.zip` file in your working directory. diff --git a/src/content/partials/cloudflare-one/tunnel/diag-host-environment.mdx b/src/content/partials/cloudflare-one/tunnel/diag-host-environment.mdx new file mode 100644 index 000000000000000..003dd21934f8386 --- /dev/null +++ b/src/content/partials/cloudflare-one/tunnel/diag-host-environment.mdx @@ -0,0 +1,26 @@ +--- +params: + - metricsURL +--- + +1. (Linux only) To include network diagnostics in the logs, allow the `cloudflared` user to create RAW and PACKET sockets without root permissions: + + ```sh + sudo setcap cap_net_raw+ep /usr/bin/traceroute && sudo setcap cap_net_raw+ep /usr/bin/traceroute + ``` + + If you do not set `cap_net_raw`, then traceroute data will be unavailable. + +2. Get diagnostic logs: + + ```sh + cloudflared tunnel diag + ``` + + If multiple instances of `cloudflared` are running on the same host, specify the metrics server IP and port for the instance you want to diagnose. For example: + + ```sh + cloudflared tunnel diag --metrics 127.0.0.1:20241 + ``` + +This command will output the status of each diagnostic task and place a `cloudflared-diag-YYYY-MM-DDThh-mm-ss.zip` file in your working directory. diff --git a/src/content/partials/cloudflare-one/tunnel/diag-kubernetes.mdx b/src/content/partials/cloudflare-one/tunnel/diag-kubernetes.mdx new file mode 100644 index 000000000000000..afa71324209ae61 --- /dev/null +++ b/src/content/partials/cloudflare-one/tunnel/diag-kubernetes.mdx @@ -0,0 +1,41 @@ +--- +params: + - metricsURL + - defaultMetricsURL +--- + +The diagnostic feature will request data from the tunnel metrics server using ports `20241` to `20245`. You will need to use port forwarding to allow the local `cloudflared` instance to connect to the metrics server on one of these ports. + +1. Determine the tunnel's metrics server port. + +2. Enable port forwarding: + + ```sh + kubectl port-forward : + ``` + + - ``: Name of the pod where the tunnel is running + - `` is any local port in the range `20241` to `20245`. + - `` is the Kubernetes pod port for the `cloudflared` instance you want to diagnose (obtained in Step 1). + + For example, if you set the metrics server address to `0.0.0.0:12345`: + + ```sh + kubectl port-forward cloudflared-6d4897585b-r8kfz 20244:12345 + ``` + + Connections made to local port `20244` are forwarded to port `12345` of the pod that is running the tunnel. + +3. Run the diagnostic: + + ```sh + cloudflared tunnel diag --diag-pod-id= + ``` + + If the pod has multiple applications/services running and `cloudflared` is not the first in the pod, you must specify either the container ID or name: + + ```sh + cloudflared tunnel diag --diag-pod-id= --diag-container-id= + ``` + +This command will output the status of each diagnostic task and place a `cloudflared-diag-YYYY-MM-DDThh-mm-ss.zip` file in your working directory. diff --git a/src/content/partials/cloudflare-one/tunnel/dns-cloudflare-settings.mdx b/src/content/partials/cloudflare-one/tunnel/dns-cloudflare-settings.mdx new file mode 100644 index 000000000000000..2f2327ca51fb9e4 --- /dev/null +++ b/src/content/partials/cloudflare-one/tunnel/dns-cloudflare-settings.mdx @@ -0,0 +1,8 @@ +--- +{} + +--- + +Published applications inherit the Cloudflare settings for their hostname, including [cache rules](/cache/how-to/cache-rules/), [WAF rules](/waf/), and other [Rules](/rules/) configurations. You can change these settings for each hostname in the [Cloudflare dashboard](https://dash.cloudflare.com/). + +If you use a load balancer, settings are applied to the load balancer hostname instead. diff --git a/src/content/partials/cloudflare-one/tunnel/dns-records-create.mdx b/src/content/partials/cloudflare-one/tunnel/dns-records-create.mdx new file mode 100644 index 000000000000000..5e148ac7da1aa5e --- /dev/null +++ b/src/content/partials/cloudflare-one/tunnel/dns-records-create.mdx @@ -0,0 +1,47 @@ +--- +params: + - certPemURL +--- + +import { TabItem, Tabs, DashButton } from "~/components"; + +To create a DNS record for a Cloudflare Tunnel: + + + +1. Log in to the [Cloudflare dashboard](https://dash.cloudflare.com/) and go to **DNS Records** for your domain. + + + +2. Select **Add record**. +3. Enter the following values: + - **Type**: _CNAME_ + - **Name**: Subdomain of your application + - **Target**: `.cfargotunnel.com` +4. Select **Save**. + +![Example of fields completed to create a new CNAME record.](~/assets/images/cloudflare-one/connections/connect-apps/dns/dns-record.png) + + + + + +For locally-managed tunnels, run the following command to create a CNAME record pointing to your tunnel subdomain: + +```sh +cloudflared tunnel route dns www.app.com +``` + +This creates a CNAME record but does not proxy traffic unless the tunnel is running. + +:::note +To create DNS records using `cloudflared`, the `cert.pem` file must be installed on your system. +::: + + + + + +The DNS record and the tunnel are independent. You can create DNS records that point to a tunnel that is not running. If a tunnel stops, the DNS record is not deleted — visitors will see a `1016` error. + +You can also create multiple DNS records pointing to the same tunnel subdomain. If you route traffic from multiple hostnames to multiple services, create a CNAME entry for each hostname. All entries share the same target. diff --git a/src/content/partials/cloudflare-one/tunnel/dns-records-intro.mdx b/src/content/partials/cloudflare-one/tunnel/dns-records-intro.mdx new file mode 100644 index 000000000000000..f3c26351bc152ee --- /dev/null +++ b/src/content/partials/cloudflare-one/tunnel/dns-records-intro.mdx @@ -0,0 +1,8 @@ +--- +{} + +--- + +When you create a tunnel, Cloudflare generates a subdomain at `.cfargotunnel.com`. You point a CNAME record at this subdomain to route traffic from your hostname to the tunnel. + +The `cfargotunnel.com` subdomain only proxies traffic for DNS records in the same Cloudflare account. If someone discovers your tunnel UUID, they cannot create a DNS record in another account to proxy traffic through it. diff --git a/src/content/partials/cloudflare-one/tunnel/filter-logs.mdx b/src/content/partials/cloudflare-one/tunnel/filter-logs.mdx new file mode 100644 index 000000000000000..6c50a4d38d46d4a --- /dev/null +++ b/src/content/partials/cloudflare-one/tunnel/filter-logs.mdx @@ -0,0 +1,16 @@ +--- +params: + - loglevelURL +--- + +You can filter logs by event type (`--event`), event level (`--level`), or sampling rate (`-sampling`) to reduce the volume of logs streamed from the origin. This helps mitigate the performance impact on the origin, especially when the origin is normally under high load. For example: + +```sh +cloudflared tail --level debug +``` + +| Flag | Description | Allowed values | Default value | +| ------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------- | ------------- | +| `--event` | Filter by the type of event / request. | `cloudflared`, `http`, `tcp`, `udp` | All events | +| `--level` | Return logs at this level and above. Works independently of the `--loglevel` setting on the server. | `debug`, `info`, `warn`, `error`, `fatal` | `debug` | +| `--sampling` | Sample a fraction of the total logs. | Number from `0.0` to `1.0` | `1.0` | diff --git a/src/content/partials/cloudflare-one/tunnel/firewall-required-ports.mdx b/src/content/partials/cloudflare-one/tunnel/firewall-required-ports.mdx new file mode 100644 index 000000000000000..45ac0379be83af3 --- /dev/null +++ b/src/content/partials/cloudflare-one/tunnel/firewall-required-ports.mdx @@ -0,0 +1,16 @@ +--- +{} + +--- + +#### `region1.v2.argotunnel.com` + +| IPv4 | IPv6 | Port | Protocols | +| ----------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ---- | ------------------------ | +| `198.41.192.167` `198.41.192.67` `198.41.192.57` `198.41.192.107` `198.41.192.27` `198.41.192.7` `198.41.192.227` `198.41.192.47` `198.41.192.37` `198.41.192.77` | `2606:4700:a0::1` `2606:4700:a0::2` `2606:4700:a0::3` `2606:4700:a0::4` `2606:4700:a0::5` `2606:4700:a0::6` `2606:4700:a0::7` `2606:4700:a0::8` `2606:4700:a0::9` `2606:4700:a0::10` | 7844 | TCP/UDP (`http2`/`quic`) | + +#### `region2.v2.argotunnel.com` + +| IPv4 | IPv6 | Port | Protocols | +| ------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ---- | ------------------------ | +| `198.41.200.13` `198.41.200.193` `198.41.200.33` `198.41.200.233` `198.41.200.53` `198.41.200.63` `198.41.200.113` `198.41.200.73` `198.41.200.43` `198.41.200.23` | `2606:4700:a8::1` `2606:4700:a8::2` `2606:4700:a8::3` `2606:4700:a8::4` `2606:4700:a8::5` `2606:4700:a8::6` `2606:4700:a8::7` `2606:4700:a8::8` `2606:4700:a8::9` `2606:4700:a8::10` | 7844 | TCP/UDP (`http2`/`quic`) | diff --git a/src/content/partials/cloudflare-one/tunnel/firewall-sni-hostnames.mdx b/src/content/partials/cloudflare-one/tunnel/firewall-sni-hostnames.mdx new file mode 100644 index 000000000000000..2bbe162b8d986ef --- /dev/null +++ b/src/content/partials/cloudflare-one/tunnel/firewall-sni-hostnames.mdx @@ -0,0 +1,13 @@ +--- +{} + +--- + +If your firewall enforces Server Name Indication (SNI), also allow these hostnames on port `7844`: + +| Hostname | Port | Protocols | +| --------------------------------------- | ---- | ------------------------ | +| `_v2-origintunneld._tcp.argotunnel.com` | 7844 | TCP (`http2`) | +| `cftunnel.com` | 7844 | TCP/UDP (`http2`/`quic`) | +| `h2.cftunnel.com` | 7844 | TCP (`http2`) | +| `quic.cftunnel.com` | 7844 | UDP (`quic`) | diff --git a/src/content/partials/cloudflare-one/tunnel/firewall-us-region-ports.mdx b/src/content/partials/cloudflare-one/tunnel/firewall-us-region-ports.mdx new file mode 100644 index 000000000000000..23052458507d147 --- /dev/null +++ b/src/content/partials/cloudflare-one/tunnel/firewall-us-region-ports.mdx @@ -0,0 +1,18 @@ +--- +params: + - regionURL +--- + +When using the `--region us` flag, allow outbound connections to these destinations instead. + +#### `us-region1.v2.argotunnel.com` + +| IPv4 | IPv6 | Port | Protocol | +| ------------------------------------------------------------------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ---- | ------------------------ | +| `198.41.218.1` `198.41.218.2` `198.41.218.3` `198.41.218.4` `198.41.218.5` `198.41.218.6` `198.41.218.7` `198.41.218.8` `198.41.218.9` `198.41.218.10` | `2606:4700:a1::1` `2606:4700:a1::2` `2606:4700:a1::3` `2606:4700:a1::4` `2606:4700:a1::5` `2606:4700:a1::6` `2606:4700:a1::7` `2606:4700:a1::8` `2606:4700:a1::9` `2606:4700:a1::10` | 7844 | TCP/UDP (`http2`/`quic`) | + +#### `us-region2.v2.argotunnel.com` + +| IPv4 | IPv6 | Port | Protocol | +| ------------------------------------------------------------------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ---- | ------------------------ | +| `198.41.219.1` `198.41.219.2` `198.41.219.3` `198.41.219.4` `198.41.219.5` `198.41.219.6` `198.41.219.7` `198.41.219.8` `198.41.219.9` `198.41.219.10` | `2606:4700:a9::1` `2606:4700:a9::2` `2606:4700:a9::3` `2606:4700:a9::4` `2606:4700:a9::5` `2606:4700:a9::6` `2606:4700:a9::7` `2606:4700:a9::8` `2606:4700:a9::9` `2606:4700:a9::10` | 7844 | TCP/UDP (`http2`/`quic`) | diff --git a/src/content/partials/cloudflare-one/tunnel/load-balancer-create.mdx b/src/content/partials/cloudflare-one/tunnel/load-balancer-create.mdx new file mode 100644 index 000000000000000..492d7edb9a1dfb2 --- /dev/null +++ b/src/content/partials/cloudflare-one/tunnel/load-balancer-create.mdx @@ -0,0 +1,39 @@ +--- +params: + - publishedAppRouteURL + - tunnelIdLocation +--- + +import { DashButton } from "~/components"; + +To create a load balancer for Cloudflare Tunnel published applications: + +1. In the Cloudflare dashboard, go to the **Load Balancing** page. + + + +2. Select **Create load balancer**, then select **Public load balancer**. +3. Under **Select website**, select the domain of your published application route. +4. On the **Hostname** page, enter a hostname for the load balancer (for example, `lb.example.com`). +5. On the **Pools** page, select **Create a pool** and enter a descriptive name. +6. Add a tunnel endpoint with the following values: + - **Endpoint Name**: Name of the server running the application + - **Endpoint Address**: `.cfargotunnel.com` (find the Tunnel ID in {props.tunnelIdLocation}) + - **Header value**: Hostname of your published application route (for example, `app.example.com`) + - **Weight**: `1` (if only one endpoint) + + :::note + A single origin pool cannot reference the same tunnel UUID twice. + ::: + +7. Choose a **Fallback pool**. Refer to [traffic steering policies](/load-balancing/understand-basics/traffic-steering/steering-policies/) for routing options. +8. (Recommended) On the **Monitors** page, attach a monitor to the endpoint. For an HTTP or HTTPS application, create an HTTPS monitor: + - **Type**: _HTTPS_ + - **Path**: `/` + - **Port**: `443` + - **Expected Code(s)**: `200` + - **Header Name**: `Host` + - **Value**: `app.example.com` +9. Save and deploy the load balancer. + +To test, access your application using the load balancer hostname (`lb.example.com`). diff --git a/src/content/partials/cloudflare-one/tunnel/load-balancer-local-connection.mdx b/src/content/partials/cloudflare-one/tunnel/load-balancer-local-connection.mdx new file mode 100644 index 000000000000000..0afc09f39b747e6 --- /dev/null +++ b/src/content/partials/cloudflare-one/tunnel/load-balancer-local-connection.mdx @@ -0,0 +1,10 @@ +--- +params: + - replicasURL +--- + +If you notice traffic imbalances across endpoints in different locations, you may need to adjust your load balancer configuration. + +Cloudflare uses [Anycast routing](https://www.cloudflare.com/learning/cdn/glossary/anycast-network/) to direct end user requests to the nearest data center. `cloudflared` prefers to serve requests using connections in the same data center, which can affect how traffic is distributed across endpoints. + +If you run `cloudflared` replicas on the same tunnel UUID, consider switching to separate tunnels for more granular control over [traffic steering](/load-balancing/understand-basics/traffic-steering/). diff --git a/src/content/partials/cloudflare-one/tunnel/load-balancer-tcp-monitors.mdx b/src/content/partials/cloudflare-one/tunnel/load-balancer-tcp-monitors.mdx new file mode 100644 index 000000000000000..00915193311f7b7 --- /dev/null +++ b/src/content/partials/cloudflare-one/tunnel/load-balancer-tcp-monitors.mdx @@ -0,0 +1,20 @@ +--- +params: + - publishedAppRouteURL +--- + +TCP monitors are not supported for tunnel endpoints. Instead, create a health check endpoint on the `cloudflared` host and use an HTTPS monitor. For example, you can use `cloudflared` to return a fixed HTTP status response: + +1. Add a published application route for the health check: + - **Hostname**: `health-check.example.com` + - **Service Type**: _HTTP_STATUS_ + - **HTTP Status Code**: `200` +2. [Create a monitor](/load-balancing/monitors/create-monitor/) with these settings: + - **Type**: _HTTPS_ + - **Path**: `/` + - **Port**: `443` + - **Expected Code(s)**: `200` + - **Header Name**: `Host` + - **Value**: `health-check.example.com` + +This monitor verifies that `cloudflared` is reachable. It does not check whether the upstream service is accepting requests. diff --git a/src/content/partials/cloudflare-one/tunnel/metrics-cloudflared.mdx b/src/content/partials/cloudflare-one/tunnel/metrics-cloudflared.mdx new file mode 100644 index 000000000000000..4e0fc2c84e7e66e --- /dev/null +++ b/src/content/partials/cloudflare-one/tunnel/metrics-cloudflared.mdx @@ -0,0 +1,30 @@ +--- +--- + +| Name | Description | Type | Labels | +| --------------------------------------------------- | ---------------------------------------------------------------------------------------------------------- | ------- | ------------------------------------------ | +| `build_info` | Build and version information. | GAUGE | `goversion`, `revision`, `type`, `version` | +| `cloudflared_config_local_config_pushes` | Number of local configuration pushes to Cloudflare. | COUNTER | | +| `cloudflared_config_local_config_pushes_errors` | Number of errors that occurred during local configuration pushes. | COUNTER | | +| `cloudflared_orchestration_config_version` | Configuration version. | GAUGE | | +| `cloudflared_tcp_active_sessions` | Concurrent number of TCP sessions that are being proxied to any origin. | GAUGE | | +| `cloudflared_tcp_total_sessions` | Total number of TCP sessions that have been proxied to any origin. | COUNTER | | +| `cloudflared_tunnel_active_streams` | Total number of active streams. | GAUGE | | +| `cloudflared_tunnel_concurrent_requests_per_tunnel` | Concurrent number of requests proxied through each tunnel. | GAUGE | | +| `cloudflared_tunnel_ha_connections` | Number of active HA connections. | GAUGE | | +| `cloudflared_tunnel_request_errors` | Number of errors proxying to origin. | COUNTER | | +| `cloudflared_tunnel_server_locations` | Where each tunnel is connected to. `1` means current location, `0` means previous locations. | GAUGE | `connection_id`, `edge_location` | +| `cloudflared_tunnel_timer_retries` | Unacknowledged heart beats count. | GAUGE | | +| `cloudflared_tunnel_total_requests` | Number of requests proxied through all tunnels. | COUNTER | | +| `cloudflared_tunnel_tunnel_authenticate_success` | Number of successful tunnel authentication events. | COUNTER | | +| `cloudflared_tunnel_tunnel_register_success` | Number of successful tunnel registrations. | COUNTER | `rpcName` | +| `cloudflared_udp_active_sessions` | Concurrent number of UDP sessions that are being proxied to any origin. | GAUGE | | +| `cloudflared_udp_total_sessions` | Total number of UDP sessions that have been proxied to any origin. | COUNTER | | +| `coredns_panics_total` | Number of panics. | COUNTER | | +| `quic_client_closed_connections` | Number of connections that have been closed. | COUNTER | | +| `quic_client_latest_rtt` | Latest round-trip time (RTT) measured on a connection. | GAUGE | `conn_index` | +| `quic_client_lost_packets` | Number of packets that have been lost from a connection. | COUNTER | `conn_index`, `reason` | +| `quic_client_min_rtt` | Lowest RTT measured on a connection in ms. | GAUGE | `conn_index` | +| `quic_client_packet_too_big_dropped` | Number of packets received from origin that are too big to send to Cloudflare and are dropped as a result. | COUNTER | | +| `quic_client_smoothed_rtt` | Smoothed RTT calculated for a connection in ms. | GAUGE | `conn_index` | +| `quic_client_total_connections` | Number of connections initiated. For all QUIC metrics, client means the side initiating the connection. | COUNTER | | diff --git a/src/content/partials/cloudflare-one/tunnel/metrics-configure-address.mdx b/src/content/partials/cloudflare-one/tunnel/metrics-configure-address.mdx new file mode 100644 index 000000000000000..2da2ff7378dc23e --- /dev/null +++ b/src/content/partials/cloudflare-one/tunnel/metrics-configure-address.mdx @@ -0,0 +1,20 @@ +--- +params: + - updateRunParametersURL +--- + +To serve metrics on a custom IP address and port, perform these steps on the `cloudflared` host: + +1. Run the tunnel using the `--metrics` flag. For example, + + ```sh + cloudflared tunnel --metrics 127.0.0.1:60123 run my-tunnel + ``` + + :::note + If you plan to fetch metrics from another machine on the local network, replace `127.0.0.1` with the internal IP of the `cloudflared` server (for example, `198.168.x.x`). To serve metrics on all available network interfaces, use `0.0.0.0`. + ::: + +2. Verify that the metrics server is running by going to `http://localhost:60123/metrics`. This will only work if you configured a localhost IP (`127.0.0.1` or `0.0.0.0`). + +You can now export the metrics to Prometheus and Grafana to visualize and query the data. Refer to the [Grafana tutorial](/cloudflare-one/tutorials/grafana/) for instructions on getting started with these tools. diff --git a/src/content/partials/cloudflare-one/tunnel/metrics-default-address.mdx b/src/content/partials/cloudflare-one/tunnel/metrics-default-address.mdx new file mode 100644 index 000000000000000..9988a3eb7cfa45d --- /dev/null +++ b/src/content/partials/cloudflare-one/tunnel/metrics-default-address.mdx @@ -0,0 +1,12 @@ +--- +params: + - logsURL +--- + +In non-containerized environments, `cloudflared` starts the metrics server on `127.0.0.1:/metrics`, where `` is the first available port in the range `20241` to `20245`. If all ports are unavailable, `cloudflared` binds to a random port. In containerized environments (Docker, Kubernetes), the default address is `0.0.0.0:/metrics`. + +To determine the default port, check your tunnel logs around the time when the tunnel started. For example: + +```text +2024-12-19T21:17:58Z INF Starting metrics server on 127.0.0.1:20241/metrics +``` diff --git a/src/content/partials/cloudflare-one/tunnel/metrics-go-runtime.mdx b/src/content/partials/cloudflare-one/tunnel/metrics-go-runtime.mdx new file mode 100644 index 000000000000000..c9b4e30ac62b994 --- /dev/null +++ b/src/content/partials/cloudflare-one/tunnel/metrics-go-runtime.mdx @@ -0,0 +1,29 @@ +--- +--- + +| Name | Description | Type | Labels | +| ---------------------------------- | ------------------------------------------------------------------ | ------- | --------- | +| `go_gc_duration_seconds` | A summary of the pause duration of garbage collection cycles. | SUMMARY | | +| `go_goroutines` | Number of goroutines that currently exist. | GAUGE | | +| `go_info` | Information about the Go environment. | GAUGE | `version` | +| `go_memstats_alloc_bytes` | Number of bytes allocated and still in use. | GAUGE | | +| `go_memstats_alloc_bytes_total` | Total number of bytes allocated, even if freed. | COUNTER | | +| `go_memstats_buck_hash_sys_bytes` | Number of bytes used by the profiling bucket hash table. | GAUGE | | +| `go_memstats_frees_total` | Total number of frees. | COUNTER | | +| `go_memstats_gc_sys_bytes` | Number of bytes used for garbage collection system metadata. | GAUGE | | +| `go_memstats_heap_alloc_bytes` | Number of heap bytes allocated and still in use. | GAUGE | | +| `go_memstats_heap_idle_bytes` | Number of heap bytes waiting to be used. | GAUGE | | +| `go_memstats_heap_inuse_bytes` | Number of heap bytes that are in use. | GAUGE | | +| `go_memstats_heap_objects` | Number of allocated objects. | GAUGE | | +| `go_memstats_heap_released_bytes` | Number of heap bytes released to OS. | GAUGE | | +| `go_memstats_heap_sys_bytes` | Number of heap bytes obtained from system. | GAUGE | | +| `go_memstats_last_gc_time_seconds` | Number of seconds since 1970 of last garbage collection. | GAUGE | | +| `go_memstats_lookups_total` | Total number of pointer lookups. | COUNTER | | +| `go_memstats_mallocs_total` | Total number of mallocs. | COUNTER | | +| `go_memstats_mcache_inuse_bytes` | Number of bytes in use by mcache structures. | GAUGE | | +| `go_memstats_mcache_sys_bytes` | Number of bytes used for mcache structures obtained from system. | GAUGE | | +| `go_memstats_mspan_inuse_bytes` | Number of bytes in use by mspan structures. | GAUGE | | +| `go_memstats_mspan_sys_bytes` | Number of bytes used for mspan structures obtained from system. | GAUGE | | +| `go_memstats_next_gc_bytes` | Number of heap bytes when next garbage collection will take place. | GAUGE | | +| `go_memstats_other_sys_bytes` | Number of bytes used for other system allocations. | GAUGE | | +| `go_memstats_stack_inuse_bytes` | Number of bytes in use by the stack allocator. | GAUGE | | diff --git a/src/content/partials/cloudflare-one/tunnel/metrics-intro.mdx b/src/content/partials/cloudflare-one/tunnel/metrics-intro.mdx new file mode 100644 index 000000000000000..ef5c8feea1a9a82 --- /dev/null +++ b/src/content/partials/cloudflare-one/tunnel/metrics-intro.mdx @@ -0,0 +1,4 @@ +--- +--- + +Tunnel metrics show a Cloudflare Tunnel's throughput and resource usage over time. When you run a tunnel, `cloudflared` will spin up a Prometheus metrics endpoint — an HTTP server that exposes metrics in [Prometheus](https://prometheus.io/docs/introduction/overview/) format. You can use the Prometheus toolkit on a remote machine to scrape metrics data from the `cloudflared` server. diff --git a/src/content/partials/cloudflare-one/tunnel/metrics-prometheus.mdx b/src/content/partials/cloudflare-one/tunnel/metrics-prometheus.mdx new file mode 100644 index 000000000000000..cec7d984e3bba42 --- /dev/null +++ b/src/content/partials/cloudflare-one/tunnel/metrics-prometheus.mdx @@ -0,0 +1,7 @@ +--- +--- + +| Name | Description | Type | Labels | +| -------------------------------------------- | -------------------------------------------- | ------- | ------ | +| `promhttp_metric_handler_requests_in_flight` | Current number of scrapes being served. | GAUGE | | +| `promhttp_metric_handler_requests_total` | Total number of scrapes by HTTP status code. | COUNTER | `code` | diff --git a/src/content/partials/cloudflare-one/tunnel/origin-parameters.mdx b/src/content/partials/cloudflare-one/tunnel/origin-parameters.mdx new file mode 100644 index 000000000000000..d01147c5a4cd003 --- /dev/null +++ b/src/content/partials/cloudflare-one/tunnel/origin-parameters.mdx @@ -0,0 +1,196 @@ +--- +params: + - updateOriginConfigURL + - locallyManagedTunnelURL + - configurationFileURL + - kubectlTutorialURL + - validatingJwtURL +--- + +Origin configuration parameters determine how `cloudflared` proxies traffic to your origin server. For a remotely-managed tunnel (created via the dashboard or API), configure these settings using the dashboard or API. If you are using a locally-managed tunnel, add these parameters to your configuration file. + +## TLS settings + +### originServerName + +| Default | UI name | +| ------- | ------------------ | +| `""` | Origin Server Name | + +Hostname that `cloudflared` should expect from your origin server certificate. If null, the expected hostname is the service URL, for example `localhost` if the service is `https://localhost:443`. + +### matchSNItoHost + +| Default | UI name | +| ------- | ----------------- | +| `false` | Match SNI to Host | + +When `true`, `cloudflared` will automatically set the Server Name Indication (SNI) during the TLS handshake to the hostname of the incoming request. + +This setting is useful when directing traffic to entry points that host multiple services and rely on SNI to route requests or present the correct certificate. It eliminates the need to explicitly configure [`originServerName`](#originservername) for individual services when using wildcard routing. + +### caPool + +| Default | UI name | +| ------- | -------------------------- | +| `""` | Certificate Authority Pool | + +Local file path to the certificate authority (CA) for your origin server certificate (for example, `/root/certs/ca.pem`). The path should point to a certificate store file or a bundle file in `.pem` or `.crt` format that contains one or more trusted root CA certificates. You should only configure this setting if your certificate is not signed by Cloudflare. + +### noTLSVerify + +| Default | UI name | +| ------- | ------------- | +| `false` | No TLS Verify | + +When `false`, TLS verification is performed on the certificate presented by your origin. + +When `true`, TLS verification is disabled. This will allow any certificate from the origin to be accepted. + +### tlsTimeout + +| Default | UI name | +| ------- | ----------- | +| `10s` | TLS Timeout | + +Timeout for completing a TLS handshake to your origin server, if you have chosen to connect Tunnel to an HTTPS server. + +### http2Origin + +| Default | UI name | +| ------- | ---------------- | +| `false` | HTTP2 connection | + +When `false`, `cloudflared` will connect to your origin with HTTP/1.1. + +When `true`, `cloudflared` will attempt to connect to your origin server using HTTP/2.0 instead of HTTP/1.1. HTTP/2.0 is a faster protocol for high traffic origins but requires you to deploy an SSL certificate on the origin. We recommend using this setting in conjunction with [noTLSVerify](#notlsverify) so that you can use a self-signed certificate. + +## HTTP settings + +### httpHostHeader + +| Default | UI name | +| ------- | ---------------- | +| `""` | HTTP Host Header | + +Sets the HTTP `Host` header on requests sent to the local service. + +### disableChunkedEncoding + +| Default | UI name | +| ------- | ------------------------ | +| `false` | Disable Chunked Encoding | + +When `false`, `cloudflared` performs chunked transfer encoding when transferring data over HTTP/1.1. + +When `true`, chunked transfer encoding is disabled. This is useful if you are running a Web Server Gateway Interface (WSGI) server. + +## Connection settings + +### connectTimeout + +| Default | UI name | +| ------- | --------------- | +| `30s` | Connect Timeout | + +Timeout for establishing a new TCP connection to your origin server. This excludes the time taken to +establish TLS, which is controlled by tlsTimeout. + +### noHappyEyeballs + +| Default | UI name | +| ------- | ----------------- | +| `false` | No Happy Eyeballs | + +When `false`, `cloudflared` uses the Happy Eyeballs algorithm for IPv4/IPv6 fallback if your local network has misconfigured one of the protocols. + +When `true`, Happy Eyeballs is disabled. + +### proxyType + +| Default | UI name | +| ------- | ---------- | +| `""` | Proxy Type | + +`cloudflared` starts a proxy server to translate HTTP traffic into TCP when proxying, for example, SSH or RDP. +This configures what type of proxy will be started. Valid options are: + +* `""` for the regular proxy +* `"socks"` for a SOCKS5 proxy. Refer to the tutorial on connecting through Cloudflare Access using kubectl for more information. + +### proxyAddress + +:::note + +For locally-managed tunnels only. +::: + +| Default | UI name | +| ----------- | ------- | +| `127.0.0.1` | -- | + +`cloudflared` starts a proxy server to translate HTTP traffic into TCP when proxying, for example, SSH or RDP. +This configures the listen address for that proxy. + +### proxyPort + +:::note + +For locally-managed tunnels only. +::: + +| Default | UI name | +| ------- | ------- | +| `0` | -- | + +`cloudflared` starts a proxy server to translate HTTP traffic into TCP when proxying, for example, SSH or RDP. +This configures the listen port for that proxy. If set to zero, an unused port will randomly be chosen. + +### keepAliveTimeout + +| Default | UI name | +| ------- | ------------------------------- | +| `1m30s` | Idle Connection Expiration Time | + +Timeout after which an idle keepalive connection can be discarded. + +### keepAliveConnections + +| Default | UI name | +| ------- | ---------------------- | +| `100` | Keep Alive Connections | + +Default: `100` + +Maximum number of idle keepalive connections between Cloudflare and your origin. This does not restrict the total number of concurrent connections. + +### tcpKeepAlive + +| Default | UI name | +| ------- | ----------------------- | +| `30s` | TCP Keep Alive Interval | + +Default: `30s` + +The timeout after which a TCP keepalive packet is sent on a connection between Cloudflare and the origin server. + +## Access settings + +### access + +| Default | UI name | +| ------- | ------------------- | +| `""` | Protect with Access | + +Requires `cloudflared` to validate the Cloudflare Access JWT prior to proxying traffic to your origin. You can enforce this check on public hostname services that are protected by an Access application. For all L7 requests to these hostnames, Access will send the JWT to `cloudflared` as a `Cf-Access-Jwt-Assertion` request header. + +To enable this security control in a configuration file, [get the AUD tag](/cloudflare-one/access-controls/applications/http-apps/authorization-cookie/validating-json/#get-your-aud-tag) for your Access application and add the following rule to `originRequest`: + +```yml +access: + required: true + teamName: + audTag: + - + - +``` diff --git a/src/content/partials/cloudflare-one/tunnel/port-configuration.mdx b/src/content/partials/cloudflare-one/tunnel/port-configuration.mdx new file mode 100644 index 000000000000000..465ed479bf6c2f1 --- /dev/null +++ b/src/content/partials/cloudflare-one/tunnel/port-configuration.mdx @@ -0,0 +1,35 @@ +--- +--- + +import { TabItem, Tabs } from "~/components"; + + + +To increase the number of ports available to `cloudflared` on Linux: + +If your machine has a `/etc/sysctl.d/` directory: + +```sh +echo 'net.ipv4.ip_local_port_range = 11000 60999' | sudo tee -a /etc/sysctl.d/99-cloudflared.conf +sudo sysctl -p /etc/sysctl.d/99-cloudflared.conf +``` + +Otherwise: + +```sh +echo 'net.ipv4.ip_local_port_range = 11000 60999' | sudo tee -a /etc/sysctl.conf +sudo sysctl -p /etc/sysctl.conf +``` + + + +To increase the number of ports available to `cloudflared` on Windows, set the [dynamic port range](https://learn.microsoft.com/en-us/troubleshoot/windows-client/networking/tcp-ip-port-exhaustion-troubleshooting) for TCP and UDP: + +```txt +netsh int ipv4 set dynamicport tcp start=11000 num=50000 +netsh int ipv4 set dynamicport udp start=11000 num=50000 +netsh int ipv6 set dynamicport tcp start=11000 num=50000 +netsh int ipv6 set dynamicport udp start=11000 num=50000 +``` + + diff --git a/src/content/partials/cloudflare-one/tunnel/protocols-table.mdx b/src/content/partials/cloudflare-one/tunnel/protocols-table.mdx new file mode 100644 index 000000000000000..5c7b3a1e010c41f --- /dev/null +++ b/src/content/partials/cloudflare-one/tunnel/protocols-table.mdx @@ -0,0 +1,21 @@ +--- +params: + - disableTlsVerificationURL + - locallyManagedTunnelsURL +--- + +The table below lists the service types you can route to a public hostname. Non-HTTP services require [installing `cloudflared` on the client](/cloudflare-one/access-controls/applications/non-http/cloudflared-authentication/) for end users to connect. + +| Service type | Description | Example `service` value | +| ------------ | ----------- | ----------------------- | +| HTTP | Proxies incoming HTTPS requests to your local web service over HTTP. | `http://localhost:8000` | +| HTTPS | Proxies incoming HTTPS requests directly to your local web service. You can disable TLS verification for self-signed certificates. | `https://localhost:8000` | +| UNIX | Same as HTTP, but uses a Unix socket. | `unix:/home/production/echo.sock` | +| UNIX + TLS | Same as HTTPS, but uses a Unix socket. | `unix+tls:/home/production/echo.sock` | +| TCP | Streams TCP over a WebSocket connection. End users run `cloudflared access tcp` to [connect](/cloudflare-one/access-controls/applications/non-http/cloudflared-authentication/arbitrary-tcp/). For long-lived connections, use [WARP-to-Tunnel](/cloudflare-one/networks/connectors/cloudflare-tunnel/private-net/cloudflared/) instead. | `tcp://localhost:2222` | +| SSH | Streams SSH over a WebSocket connection. End users run `cloudflared access ssh` to [connect](/cloudflare-one/networks/connectors/cloudflare-tunnel/use-cases/ssh/ssh-cloudflared-authentication/). For long-lived connections, use [WARP-to-Tunnel](/cloudflare-one/networks/connectors/cloudflare-tunnel/use-cases/ssh/ssh-infrastructure-access/) instead. | `ssh://localhost:22` | +| RDP | Streams RDP over a WebSocket connection. For more information, refer to [Connect to RDP with client-side cloudflared](/cloudflare-one/networks/connectors/cloudflare-tunnel/use-cases/rdp/rdp-cloudflared-authentication/). | `rdp://localhost:3389` | +| SMB | Streams SMB over a WebSocket connection. For more information, refer to [Connect to SMB with client-side cloudflared](/cloudflare-one/networks/connectors/cloudflare-tunnel/use-cases/smb/#connect-to-smb-server-with-cloudflared-access). | `smb://localhost:445` | +| HTTP_STATUS | Responds to all requests with a fixed HTTP status code. | `http_status:404` | +| BASTION | Allows `cloudflared` to act as a jump host, providing access to any local address. | `bastion` | +| HELLO_WORLD | Test server for validating your Cloudflare Tunnel connection (for locally managed tunnels only). | `hello_world` | diff --git a/src/content/partials/cloudflare-one/tunnel/run-parameters.mdx b/src/content/partials/cloudflare-one/tunnel/run-parameters.mdx new file mode 100644 index 000000000000000..daf01387a4ac358 --- /dev/null +++ b/src/content/partials/cloudflare-one/tunnel/run-parameters.mdx @@ -0,0 +1,200 @@ +--- +params: + - updateRunParametersURL + - locallyManagedTunnelURL + - configurationFileURL + - metricsURL + - usageMetricsURL + - tunnelWithFirewallURL + - tunnelPermissionsURL + - createRemoteTunnelURL + - faqURL +--- + +import { Render } from "~/components"; + +This page lists the configuration flags for the `cloudflared tunnel run` command. For a remotely-managed tunnel (created via the dashboard or API), add these flags to the tunnel service. If you are using a locally-managed tunnel, add these flags to your configuration file as key/value pairs. + +## `autoupdate-freq` + +| Syntax | Default | +| ---------------------------------------------------------------- | ------- | +| `cloudflared tunnel --autoupdate-freq run ` | `24h` | + +Configures the frequency of `cloudflared` updates. + +By default, `cloudflared` will periodically check for updates and restart with the new version. Restarts are performed by spawning a new process that connects to the Cloudflare global network. On successful connection, the old process will gracefully shut down after handling all outstanding requests. See also: [`no-autoupdate`](#no-autoupdate). + +## `config` + +:::note + +For locally-managed tunnels only. +::: + +| Syntax | Default | +| ------------------------------------------------------- | --------------------------- | +| `cloudflared tunnel --config run ` | `~/.cloudflared/config.yml` | + +Specifies the path to a configuration file in YAML format. + +## `edge-bind-address` + +| Syntax | Environment Variable | +| ---------------------------------------------------------------- | -------------------------- | +| `cloudflared tunnel --edge-bind-address run ` | `TUNNEL_EDGE_BIND_ADDRESS` | + +Specifies the outgoing IP address used to establish a connection between `cloudflared` and the Cloudflare global network. + +By default, `cloudflared` lets the operating system decide which IP address to use. This option is useful if you have multiple network interfaces available and want to prefer a specific interface. + +The IP version of `edge-bind-address` will override [`edge-ip-version`](#edge-ip-version) (if provided). For example, if you enter an IPv6 source address, `cloudflared` will always connect to an IPv6 destination. + +## `edge-ip-version` + +| Syntax | Default | Environment Variable | +| ------------------------------------------------------------------- | ------- | ------------------------ | +| `cloudflared tunnel --edge-ip-version run ` | `4` | `TUNNEL_EDGE_IP_VERSION` | + +Specifies the IP address version (IPv4 or IPv6) used to establish a connection between `cloudflared` and the Cloudflare global network. Available values are `auto`, `4`, and `6`. + +The value `auto` relies on the host operating system to determine which IP version to select. The first IP version returned from the DNS resolution of the region lookup will be used as the primary set. In dual IPv6 and IPv4 network setups, `cloudflared` will separate the IP versions into two address sets that will be used to fallback in connectivity failure scenarios. + +## `grace-period` + +| Syntax | Default | Environment Variable | +| --------------------------------------------------------------- | ------- | --------------------- | +| `cloudflared tunnel --grace-period run ` | `30s` | `TUNNEL_GRACE_PERIOD` | + +When `cloudflared` receives SIGINT/SIGTERM it will stop accepting new requests, wait for in-progress requests to terminate, then shut down. Waiting for in-progress requests will timeout after this grace period, or when a second SIGTERM/SIGINT is received. + +## `logfile` + +| Syntax | Environment Variable | +| -------------------------------------------------------- | -------------------- | +| `cloudflared tunnel --logfile run ` | `TUNNEL_LOGFILE` | + +Saves application log to this file. Mainly useful for reporting issues. For more details on what information you need when contacting Cloudflare support, refer to this guide. + +## `loglevel` + +| Syntax | Default | Environment Variable | +| ---------------------------------------------------------- | ------- | -------------------- | +| `cloudflared tunnel --loglevel run ` | `info` | `TUNNEL_LOGLEVEL` | + +Specifies the verbosity of logging for the local `cloudflared` instance. Available values are `debug`, `info` (default), `warn`, `error`, and `fatal`. At the `debug` level, `cloudflared` will log and display the request URL, method, protocol, content length, as well as all request and response headers. However, note that this can expose sensitive information in your logs. + +## `metrics` + +| Syntax | Default | Environment Variable | +| ----------------------------------------------------------- | ------------------------------------------------------------------------------------------------ | -------------------- | +| `cloudflared tunnel --metrics run ` | Refer to Tunnel metrics | `TUNNEL_METRICS` | + +Exposes a Prometheus endpoint on the specified IP address and port, which you can then query for usage metrics. + +## `no-autoupdate` + +:::note + +Does not apply if you installed `cloudflared` using a package manager. + +::: + +| Syntax | Environment Variable | +| ------------------------------------------------------- | -------------------- | +| `cloudflared tunnel --no-autoupdate run ` | `NO_AUTOUPDATE` | + +Disables automatic `cloudflared` updates. See also: [`autoupdate-freq`](#autoupdate-freq). + +## `origincert` + +:::note + +For locally-managed tunnels only. +::: + +| Syntax | Default | Environment Variable | +| ----------------------------------------------------------- | ------------------------- | -------------------- | +| `cloudflared tunnel --origincert run ` | `~/.cloudflared/cert.pem` | `TUNNEL_ORIGIN_CERT` | + +Specifies the account certificate for one of your zones, authorizing the client to serve as an origin for that zone. You can obtain a certificate by using the `cloudflared tunnel login` command or by visiting `https://dash.cloudflare.com/argotunnel`. + +## `pidfile` + +| Syntax | Environment Variable | +| -------------------------------------------------------- | -------------------- | +| `cloudflared tunnel --pidfile run ` | `TUNNEL_PIDFILE` | + +Writes the application's process identifier (PID) to this file after the first successful connection. Mainly useful for scripting and service integration. + +## `post-quantum` + +| Syntax | Environment Variable | +| ------------------------------------------------------ | --------------------- | +| `cloudflared tunnel run --post-quantum ` | `TUNNEL_POST_QUANTUM` | + +By default, Cloudflare Tunnel connections over [`quic`](#protocol) are encrypted using [post-quantum cryptography (PQC)](/ssl/post-quantum-cryptography/) but will fall back to non-PQ if there are issues connecting. If the `--post-quantum` flag is provided, `quic` connections are only allowed to use PQ key agreements, with no fallback to non-PQ. + +Post-quantum key agreements are not supported when using `http2` protocol. + +## `protocol` + +| Syntax | Default | Environment Variable | +| ---------------------------------------------------------- | ------- | --------------------------- | +| `cloudflared tunnel --protocol run ` | `auto` | `TUNNEL_TRANSPORT_PROTOCOL` | + +Specifies the protocol used to establish a connection between `cloudflared` and the Cloudflare global network. Available values are `auto`, `http2`, and `quic`. + +The `auto` value will automatically configure the `quic` protocol. If `cloudflared` is unable to establish UDP connections, it will fallback to using the `http2` protocol. + +## `region` + +| Syntax | Environment Variable | +| -------------------------------------------------------- | -------------------- | +| `cloudflared tunnel --region run ` | `TUNNEL_REGION` | + +Allows you to choose the regions to which connections are established. Currently the only available value is `us`, which routes all connections through data centers in the United States. Omit or leave empty to connect to the global region. + +When the region is set to `us`, `cloudflared` uses different US-specific hostnames and IPs. Refer to Tunnel with firewall for details. + +## `retries` + +| Syntax | Default | Environment Variable | +| --------------------------------------------------------- | ------- | -------------------- | +| `cloudflared tunnel --retries run ` | `5` | `TUNNEL_RETRIES` | + +Specifies the maximum number of retries for connection/protocol errors. Retries use exponential backoff (retrying at 1, 2, 4, 8, 16 seconds by default), so it is not recommended that you increase this value significantly. + +## `tag` + +| Syntax | Environment Variable | +| ------------------------------------------------------- | -------------------- | +| `cloudflared tunnel --tag run ` | `TUNNEL_TAG` | + +Specifies custom tags used to identify this tunnel. Multiple tags may be specified by adding additional `--tag ` flags to the command. If entering multiple tags into a configuration file, delimit with commas: `tag: {KEY1=VALUE1, KEY2=VALUE2}`. + +## `token` + +:::note + +For remotely-managed tunnels only. +::: + +| Syntax | Environment Variable | +| ----------------------------------------------- | -------------------- | +| `cloudflared tunnel run --token ` | `TUNNEL_TOKEN` | + +Associates the `cloudflared` instance with a specific tunnel. The tunnel's token is shown in the dashboard when you first create the tunnel. You can also retrieve the token using the [API](/api/resources/zero_trust/subresources/tunnels/subresources/cloudflared/subresources/token/methods/get/). + +## `token-file` + +:::note + +For remotely-managed tunnels only. Requires `2025.4.0` or later. +::: + +| Syntax | Environment Variable | +| -------------------------------------------- | -------------------- | +| `cloudflared tunnel run --token-file ` | `TUNNEL_TOKEN_FILE` | + +Associates the `cloudflared` instance with a specific tunnel using a file which contains the token. diff --git a/src/content/partials/cloudflare-one/tunnel/tunnel-diag-file.mdx b/src/content/partials/cloudflare-one/tunnel/tunnel-diag-file.mdx index 2607e51012841a9..35a23d38040988e 100644 --- a/src/content/partials/cloudflare-one/tunnel/tunnel-diag-file.mdx +++ b/src/content/partials/cloudflare-one/tunnel/tunnel-diag-file.mdx @@ -1,21 +1,25 @@ --- -{} +params: + - runParametersURL + - logsURL + - metricsURL + - loglevelURL --- The `cloudflared-diag-YYYY-MM-DDThh-mm-ss.zip` archive contains the files listed below. The data in a file either applies to the `cloudflared` instance being diagnosed (`diagnosee`) or the instance that triggered the diagnosis (`diagnoser`). For example, if your tunnel is running in a Docker container, the diagnosee is the Docker instance and the diagnoser is the host instance. | File name | Description | Instance | | ------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------ | --------- | -| `cli-configuration.json` | [Tunnel run parameters](/cloudflare-one/networks/connectors/cloudflare-tunnel/configure-tunnels/cloudflared-parameters/run-parameters/) used when starting the tunnel | diagnosee | -| `cloudflared_logs.txt` | [Tunnel log file](/cloudflare-one/networks/connectors/cloudflare-tunnel/monitor-tunnels/logs/)[^1] | diagnosee | +| `cli-configuration.json` | Tunnel run parameters used when starting the tunnel | diagnosee | +| `cloudflared_logs.txt` | Tunnel log file[^1] | diagnosee | | `configuration.json` | Tunnel configuration parameters | diagnosee | | `goroutine.pprof` | goroutine profile made available by `pprof` | diagnosee | | `heap.pprof` | heap profile made available by `pprof` | diagnosee | -| `metrics.txt` | Snapshot of [Tunnel metrics](/cloudflare-one/networks/connectors/cloudflare-tunnel/monitor-tunnels/metrics/#available-metrics) at the time of diagnosis | diagnosee | +| `metrics.txt` | Snapshot of Tunnel metrics at the time of diagnosis | diagnosee | | `network.txt` | JSON traceroutes to Cloudflare's global network using IPv4 and IPv6 | diagnoser | | `raw-network.txt` | Raw traceroutes to Cloudflare's global network using IPv4 and IPv6 | diagnoser | | `systeminformation.json` | Operating system information and resource usage | diagnosee | | `task-result.json` | Result of each diagnostic task | diagnoser | | `tunnelstate.json` | Tunnel connections at the time of diagnosis | diagnosee | -[^1]: If the log file is blank, you may need to [set `--loglevel` to `debug`](/cloudflare-one/networks/connectors/cloudflare-tunnel/monitor-tunnels/logs/#view-logs-on-the-server) when you start the tunnel. The `--loglevel` parameter is only required if you ran the tunnel from the CLI using a `cloudflared tunnel run` command. It is not necessary if the tunnel runs as a Linux/macOS service or runs in Docker/Kubernetes. +[^1]: If the log file is blank, you may need to set `--loglevel` to `debug` when you start the tunnel. The `--loglevel` parameter is only required if you ran the tunnel from the CLI using a `cloudflared tunnel run` command. It is not necessary if the tunnel runs as a Linux/macOS service or runs in Docker/Kubernetes. diff --git a/src/content/partials/cloudflare-one/tunnel/ulimits.mdx b/src/content/partials/cloudflare-one/tunnel/ulimits.mdx new file mode 100644 index 000000000000000..dc6bc8a21920d37 --- /dev/null +++ b/src/content/partials/cloudflare-one/tunnel/ulimits.mdx @@ -0,0 +1,22 @@ +--- +--- + +On Linux and macOS, `ulimit` settings determine the system resources available to a logged-in user. We recommend configuring the following ulimits on the `cloudflared` server: + +| ulimit | Description | Value | +| ------ | ------------------------------------------------ | -------- | +| `-n` | Maximum number of open files or file descriptors | ≥ 70,000 | + +To view your current ulimits, open a terminal and run: + +```sh +ulimit -a +``` + +To set the open files `ulimit`: + +```sh +ulimit -n 70000 +``` + +The command above sets the open files limit only for the current terminal session and will not persist after a reboot or new login. To apply this limit permanently, configure it using the persistent method appropriate for your operating system. diff --git a/src/content/partials/cloudflare-one/tunnel/update-origin-configuration.mdx b/src/content/partials/cloudflare-one/tunnel/update-origin-configuration.mdx new file mode 100644 index 000000000000000..38ab148e3b71400 --- /dev/null +++ b/src/content/partials/cloudflare-one/tunnel/update-origin-configuration.mdx @@ -0,0 +1,9 @@ +--- +--- + +1. In [Cloudflare One](https://one.dash.cloudflare.com/), go to **Networks** > **Connectors** > **Cloudflare Tunnels**. +2. Choose a tunnel and select **Edit**. +3. Select the **Published application routes** tab. +4. Choose an application and select **Edit**. +5. Under **Additional application settings**, modify one or more [origin configuration parameters](/cloudflare-one/networks/connectors/cloudflare-tunnel/configure-tunnels/cloudflared-parameters/origin-parameters/). +6. Select **Save**. diff --git a/src/content/partials/cloudflare-one/tunnel/update-run-parameters.mdx b/src/content/partials/cloudflare-one/tunnel/update-run-parameters.mdx new file mode 100644 index 000000000000000..8eafe3e520b2eeb --- /dev/null +++ b/src/content/partials/cloudflare-one/tunnel/update-run-parameters.mdx @@ -0,0 +1,126 @@ +--- +--- + +import { TabItem, Tabs } from "~/components"; + + + +On Linux, Cloudflare Tunnel installs itself as a system service using `systemctl`. By default, the service will be named `cloudflared.service`. To configure your tunnel on Linux: + +1. Open `cloudflared.service`. + + ```sh + sudo systemctl edit --full cloudflared.service + ``` + +2. Modify the `cloudflared tunnel run` command with the desired configuration flag. For example, + + ```txt null {8} + [Unit] + Description=Cloudflare Tunnel + After=network.target + + [Service] + TimeoutStartSec=0 + Type=notify + ExecStart=/usr/local/bin/cloudflared tunnel --loglevel info --logfile /var/log/cloudflared/cloudflared.log run --token + Restart=on-failure + RestartSec=5s + + [Install] + WantedBy=multi-user.target + ``` + +3. Restart `cloudflared.service`: + + ```sh + sudo systemctl restart cloudflared + ``` + +4. To verify the new configuration, check the service status: + + ```sh + sudo systemctl status cloudflared + ``` + ```sh output + ● cloudflared.service - cloudflared + Loaded: loaded (/etc/systemd/system/cloudflared.service; enabled; preset: enabled) + Active: active (running) since Wed 2024-10-09 20:02:59 UTC; 2s ago + Main PID: 2157 (cloudflared) + Tasks: 8 (limit: 1136) + Memory: 16.3M + CPU: 136ms + CGroup: /system.slice/cloudflared.service + └─2157 /usr/bin/cloudflared tunnel --loglevel info --logfile /var/log/cloudflared/cloudflared.log run --token eyJhIjoi... + ``` + + + +On macOS, Cloudflare Tunnel installs itself as a launch agent using `launchctl`. By default, the agent will be called `com.cloudflare.cloudflared`. To configure your tunnel on macOS: + +1. Stop the `cloudflared` service. + + ```sh + sudo launchctl stop com.cloudflare.cloudflared + ``` + +2. Unload the configuration file. + + ```sh + sudo launchctl unload /Library/LaunchDaemons/com.cloudflare.cloudflared.plist + ``` + +3. Open `/Library/LaunchDaemons/com.cloudflare.cloudflared.plist` in a text editor. + +4. Modify the `ProgramArguments` key with the desired configuration flag. For example, + + ```txt + + + Label + com.cloudflare.cloudflared + ProgramArguments + + /opt/homebrew/bin/cloudflared + tunnel + --logfile + + --loglevel + debug + run + --token + + + ``` + +5. Load the updated configuration file. + + ```sh + sudo launchctl load /Library/LaunchDaemons/com.cloudflare.cloudflared.plist + ``` + +6. Start the `cloudflared` service. + + ```sh + sudo launchctl start com.cloudflare.cloudflared + ``` + + + +On Windows, Cloudflare Tunnel installs itself as a system service using the Registry Editor. By default, the service will be named `cloudflared`. To configure your tunnel on Windows: + +1. Open the Registry Editor. + +2. Go to **HKEY_LOCAL_MACHINE** > **SYSTEM** > **CurrentControlSet** > **Services** > **cloudflared**. + +3. Double-click **ImagePath**. + +4. Modify **Value data** with the desired configuration flag. For example, + + ```txt + C:\Program Files (x86)\cloudflared\.\cloudflared.exe tunnel --loglevel info --logfile run --token + ``` + +![Modify cloudflared service in the Registry Editor](~/assets/images/cloudflare-one/connections/connect-apps/remote-management-windows.png) + + diff --git a/src/content/partials/cloudflare-one/tunnel/view-logs-cli.mdx b/src/content/partials/cloudflare-one/tunnel/view-logs-cli.mdx new file mode 100644 index 000000000000000..f194fb638079003 --- /dev/null +++ b/src/content/partials/cloudflare-one/tunnel/view-logs-cli.mdx @@ -0,0 +1,20 @@ +--- +--- + +1. On your local machine, authenticate `cloudflared` to your Cloudflare account: + + ```sh + cloudflared tunnel login + ``` + +2. Run `cloudflared tail` for a specific tunnel: + + ```sh + cloudflared tail + ``` + + For a more structured view of the JSON message, you can pipe the output to tools like [jq](https://stedolan.github.io/jq/): + + ```sh + cloudflared tail --output=json | jq . + ``` diff --git a/src/content/partials/cloudflare-one/tunnel/view-logs-on-server.mdx b/src/content/partials/cloudflare-one/tunnel/view-logs-on-server.mdx new file mode 100644 index 000000000000000..c5d8a1638544701 --- /dev/null +++ b/src/content/partials/cloudflare-one/tunnel/view-logs-on-server.mdx @@ -0,0 +1,14 @@ +--- +params: + - loglevelURL + - logfileURL + - runParametersURL +--- + +If you have access to the origin server, you can use the `--loglevel` flag to enable logging when you start the tunnel. By default, `cloudflared` prints logs to stdout and does not store logs on the server. You can optionally use the `--logfile` flag to write your logs to a file. + +To enable logs, run the tunnel using the `--loglevel info` and `--logfile ` flags. For example, + +```sh +cloudflared tunnel --loglevel info --logfile cloudflared.log run +``` diff --git a/src/icons/cloudflare-tunnel-sase.svg b/src/icons/cloudflare-tunnel-sase.svg new file mode 100644 index 000000000000000..ddc17157b850dc7 --- /dev/null +++ b/src/icons/cloudflare-tunnel-sase.svg @@ -0,0 +1 @@ + diff --git a/src/icons/cloudflare-tunnel.svg b/src/icons/cloudflare-tunnel.svg new file mode 100644 index 000000000000000..d953c3b96820184 --- /dev/null +++ b/src/icons/cloudflare-tunnel.svg @@ -0,0 +1 @@ + diff --git a/src/icons/tunnel.svg b/src/icons/tunnel.svg new file mode 100644 index 000000000000000..d953c3b96820184 --- /dev/null +++ b/src/icons/tunnel.svg @@ -0,0 +1 @@ +