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:

1 Like

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.

Hello, it works for Firefox and Chrome. 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://