Creating service tunnel for Bitcoin

Looking at the information here,

I have configured a service trying both of the two individual methods,

tunnel: tunnelid
cred-file: /home/user/.cloudflared/tunnelid.json

  - hostname:
    service: bitcoin://localhost:8333
  - hostname:
    service: tcp://localhost:8333
  - service: http_status:404

The service is running and has plenty of inbound and outbound connections not from the Cloudflare Argo Tunnel, but my client cannot connect with

Any ideas? I guess I have not tried service: localhost:8333 but it is best to be specific. As it is the ingress rules validate.

If your client is doing pure TCP (i.e., not HTTP/L7) then you need something on the client side:


Cloudflare can render certain non-web applications in your browser…

No, this is for the public Bitcoin client to connect.

The first method I linked above can be replaced with for any arbitrary app

Okay, I have done all of that just to prove it is not working even using the legacy methods. I have plenty of other projects on Cloudflare Argo Tunnel already on port 80 and port 81 and so on just this one in on TCP port 8333.

Lets recap. I create tunnel, created DNS entry, create config.yml and validate using this Tunnel Guide

Running tunnel nothing looks like traffic coming in on port 8333

I remove DNS entry, put aside config file, run legacy mode tunnel from command line tunnel creates everything looks okay but nothing looks like traffic on port 8333 but I did diosconver using this method that there was an old legacy tunnel still running using the same subdomain name, the error was not earlier reported after I removed the DNS entry manually and after I reconfigured the other legacy tunnel this one runs fine but as I say, no traffic.

I reset everything back to using ingress rules, and, what is the solution? Thank-you for your assistance, unfortunately community can only guess but cloudflare technicians can check.

config.yml now looks like:

tunnel: tunnelid
cred-file: /home/user/.cloudflared/tunnelid.json

  - hostname:
    service: tcp://localhost:8333
  - service: http_status:404

How are you accessing

Since it is not a HTTP origin, then you must have something like:

(using cloudflared as per

  • your client accesses tcp://localhost:7333 → cloudflared access tcp --url localhost:7333 --hostname → Cloudflare Edge → cloudflared tunnel → tcp://localhost:8333

(using WARP as per

  • your client has WARP enrolled into Teams, with Gateway enabled
  • your server is on a machine with private IP (e.g.)
  • client accesses → Cloudflare Edge → cloudflared tunnel →
1 Like

It is a TCP service on port 8333

I use,

cloudflared tunnel login
cloudflared tunnel create {arbitrary.1}
cloudflared tunnel route dns {arbitrary.1}
nano config.yml
cloudflare tunnel run


tunnel: {arbitrary.1.uuid}
cred-file: /home/user/.cloudflared/{arbitrary.1.uuid}.json

  - hostname:
    service: tcp://localhost:8333
  - service: http_status:404

Usage is with this application,

$ cloudflared tunnel info bitcoin

NAME:     {arbitrary.1}
ID:       {arbitrary.1.uuid}
CREATED:  2021-11-26 21:54:47.06188 +0000 UTC

CONNECTOR ID                         CREATED              ARCHITECTURE VERSION   ORIGIN IP      EDGE         
{connector-uuid} 2021-11-26T22:03:42Z linux_amd64  2021.11.0 {Origin IP} 2xLOC, 2xLOC 

See #5 Start routing traffic for connection an application via web, just like exposing port on modem for your server, same thing if you use port 80 except choosing HTTP:// service instead of TCP:// service allows for more specific rules for HTTP service in Cloudflare backed and limits to HTTP requestes.

This is what I’ve been trying to explain. You cannot simply use any arbitrary client (including Bitcoin Core - Desktop - Linux - Choose your wallet - Bitcoin ) and point it to your domain and expect that to work for arbitrary TCP.

I’ve provided links/tutorials above to the 2 ways you can make that work. But thus far it seems like you haven’t taken a look at them since there’s no evidence of that in your latest posts.

Yes but if you do not understand the communication model any amount of tutorials cannot assist.

It works for Firefox and Chrome arbitrary client connect to my domain. HTTP://

TCP is in the list on the document I provided. It is just a different port. HTTP is a protocol on TCP/IP transport which is just what TCP means to make presumption. It is the same but you are talking legacy and I am talking ingress rules. It is linked from the other document when you read everything thoroughly. Enough now.

If you are Cloudflare access even try this one, HTTP://

Your support system is unusually drawling it detects maybe I did email not from the email address used to register my account, so I check it, it is the same email used to register my account. I will email again.


Using Tunnels for arbitrary TCP applications is only possible when both the client and server is running cloudflared. You can think of it much like a site-to-site VPN.


  • A Cloudflare account
  • A site active on Cloudflare
  • The cloudflared daemon installed on the host and client machines

If installing the cloudflared daemon on client machines is not an option, please take a look at Cloudflare Spectrum. Though please note this is a paid service and that you’ll need an Enterprise Plan to use it for arbitrary TCP/UDP applications.

1 Like

So, I can do all the things with ingress rules only for an external service if it is HTTP? This example does not say anything about wap tunnels, it connects services to domain names and shows the supported protocols. Can you show me where in the attached document it supports what you have said? In the legacy I specify the details and a portal opens. In the ingress model I follow the steps, create a named tunnel, specify DNS routing, add the ingress rules to the config.yml and run tunnel. What do you think the ingress rules are doing there?

credentials-file: /root/.cloudflared/6ff42ae2-765d-4adf-8112-31c55c1551ef.json

  # Example of a request over TCP:
  - hostname:
    service: tcp://localhost:8000
  # Example of a request over a Unix socket:
  - hostname:
    service: unix:/home/production/echo.sock
  # Example of a request mapping to the Hello World test server:
  - hostname:
    service: hello_world
  # Example of a rule responding to traffic with an HTTP status:
  - service: http_status:404

If I use the legacy method to do this on the command line with cloudflared there is no warp tunnels or anything, but in brief testing, it did not seem to work for TCP port 8333 either but it definitely works for HTTP tunnels on TCP ports 80,81,82 and so on. The legacy method is no help anyway, because of other introduced problems with DNS flattening and routing we must migrate to the ingress rules model for services to work reliably.

I read you better, it is not in the documents. I did think that it may be related to the ingress being only on port 80 and routing to the configured service, so I was going to try either pointing the client to {domain:80} or,

  - hostname:
    service: tcp://localhost:8333

I have turned off proxy and set DNS only. It is still a TCP service. It would be sensible now to think that it does not work because it is not a Spectrum service.

It is sort of a problem, I was going to put some NFS Servers online.
Is this configuration require additional, the document doesn’t say - it looks like a separate program to the Cloudflare Argo Tunnel, but you are saying I have to have a paid pro or business plan or above, the restrictions are the same?

Unless you’re using Spectrum for Minecraft or SSH, you’ll need an Enterprise Plan as albert pointed out.

I will try it. It seems crazy that Cloudflare Argo Tunnel supports all of this but we need to use Spectrum to work around restrictions unless we have Enterprise then we just use Cloudflare Argo Tunnel. At least we can be thankful that with standard Cloudflare Argo Tunnel works for HTTP service.

@sdayman @albert I cannot even find Spectrum in the dashboard any longer but I did find the rest of the information in the document Cloudflare for teams, it was shared by @nuno.diegues but I must have had it out of context. It seems crazy to do it this way considering Cloudflare Argo Tunnel is access tunnel, it is configurable, and it is just port traffic for standard TCP not even services.

Is there a link to Sepctrum on the dashboard please, I do not need browser connect, I want FTP, SSH , NFS to work from web? I just want to put server online with Cloudflare Argo Tunnel.

Cloudflare can use a single IP for multiple customers because HTTP requests include a Host header telling which site the request is intended for. Most other protocols don’t have a feature like that, so Cloudflare has to assign separate IP addresses for each application. IPv4 addresses aren’t cheap which is why this isn’t offered for free tunnels.


You’ll need Pro or higher to see the Spectrum tab in your dashboard at all. SSH is supported on the Pro plan but you’ll need Enterprise for FTP and NFS.

1 Like

@nuno.diegues has already answered the question. You need to use cloudflared on the client if you want to proxy arbitrary TCP applications through Argo tunnel.

You need to use the same client for SSH as well though the configuration is different.

1 Like