Argo Tunnel creates a secure, outbound-only connection between your services and Cloudflare by deploying a lightweight connector in your environment. With this model, your team does not need to go through the hassle of poking holes in your firewall or validating that traffic originated from Cloudflare IPs.
Special thanks to Aeleos who worked with us to develop his original guide here: https://github.com/aeleos/cloudflared
For this setup, you need to have a domain that is managed by Cloudflare, and can be done on the free plan.
Starting on the 25th of March 2022, Cloudflare has integrated tunnels and managing them through the Access section of Cloudflare. This is the GUI option if you prefer to do it that way.
If you prefer the CLI method, the below is still valid and works without issue. Both options are provided by Cloudflare.
See our video covering the GUI option instead:
First we need to make sure we have the app folder ready with the correct permissions. Thanks to this tip from our discord user @noodlemctwoodle, you can use the following command in the Unraid terminal to create the folder and set the correct permissions:
mkdir -p /mnt/user/appdata/cloudflared/ && chmod -R 777 /mnt/user/appdata/cloudflared/
In Unraid terminal, run the following command to authorize Cloudflared with the Cloudflare site you want to set up with a tunnel.
docker run -it --rm -v /mnt/user/appdata/cloudflared:/home/nonroot/.cloudflared/ cloudflare/cloudflared:latest tunnel login
It will print out a link to Cloudflare. Put this link in your web browser, and select which domain you want to use. Then, the daemon will automatically pull the certificate.
Now we need to create a tunnel. To do this, we will run another command from the Unraid terminal:
docker run -it --rm -v /mnt/user/appdata/cloudflared:/home/nonroot/.cloudflared/ cloudflare/cloudflared:latest tunnel create TUNNELNAME
This will create your tunnel's UUID.json file, which contains a secret used to authenticate your tunnelled connection with Cloudflare. The JSON file is only needed for running the tunnel, but any tunnel modifications require the cert.pem. More information about what requires what can be found here.
Make sure you copy your UUID, as this will be used in later steps. It can always be found later by the name of the JSON file.
Now we need to create a config.yaml to configure the tunnel
Now paste in the following and amend your reverse proxy IP:PORT, tunnel UUID and domain name if applicable
- if you have an ssl certificate on your reverse proxy, you need to pass in your domain name that the SSL cert is under
- if you want to proxy to an http server, use the commended ingress rule
- if you want to disable ssl verification, add noTLSVerify under originRequest
# NOTE: You should only have one ingress tag, so if you uncomment one block comment the others
# forward all traffic to Reverse Proxy w/ SSL
- service: https://REVERSEPROXYIP:PORT
#forward all traffic to Reverse Proxy w/ SSL and no TLS Verify
# - service: https://REVERSEPROXYIP:PORT
# noTLSVerify: true
# forward all traffic to reverse proxy over http
# - service: http://REVERSEPROXYIP:PORT
Now, we need to install the app inside the Unraid UI.
- Go to the CA Apps Tab
- Search for cloudflared
- Install from aeleos' Repository
- Change the
Now we need to change the "Post Arguments". To do this we need to enable the "Advanced View" in the top right corner.
- You should see the below command inside of "Post Arguments". Replace UUID the the UUID for your tunnel generated in step 2.
tunnel run UUID
Now you can start your container and if all done correctly with no errors, you should have a running tunnel!
The next step will be to edit your domain DNS records.
- If you have an A record already, you can remove this as it is now not needed.
- Replace your A record with a CNAME record, that points to the domain root (@) and for the content, you need to add UUID.cfargotunnel.com (inserting your UUID that was copied earlier).
You should now be able to access all of your apps without needed a port forward!
If you see an error like
Unable to reach the origin service. The service may be down or it may not be responding to traffic from cloudflared: x509: certificate is not valid for any names, but wanted to match youdomain.com
In your config.yml try changing
appis a valid subdomain that you have a DNS record for (configured in both cloudflare and your reverse proxy). Despite this being a specific hostname, cloudflared should be able to use this subdomain to verify certificates for your other subdomains as they pass through the tunnel.
- service: https://192.168.1.20:18443
If you are receiving an error like the following, it could be due to the config file being named incorrectly or is stored in the wrong location.
Cannot determine default configuration path. No file [config.yml config.yaml] in [~/.cloudflared ~/.cloudflare-warp ~/cloudflare-warp /etc/cloudflared /usr/local/etc/cloudflared]bash
error="Unable to reach the origin service. The service may be down or it may not be responding to traffic from cloudflared: dial tcp 127.0.0.1:8080: connect: connection refused" cfRay=XXXXXXXXXXXX-NRT originService=http://localhost:8080
As you can see, the logs are stating that it cannot access the config.yml file and so it uses the default configuration and points to the origin server
Make sure that your config file is named
config.ymland is stored in the root directory of the appdata
What is quic connection? Quic is a new encrypted transport layer network protocol that makes HTTP traffic more secure, efficient, and faster. However, there are certain ISP's do not support this protocol, which can interfere with your Cloudflare Tunneling.
If you receiving an error like the following below in your Cloudflared Docker App Logs:
2023-02-01T20:02:54Z INF Connection adb2ac3b-edae-4671-9004-c416549fce47 registered with protocol: quicconnIndex-0 ip-220.127.116.11 location=SEA
2023-02-0120:02:54Z INF Connection 8082a744-ab41-4386-9086-2da1c0c89c4 registered with protocol: quic connIndex-1 ip-18.104.22.168 location-LAX
2023-02-01720:02:54Z INF Connection 9855f585-290a-4f8-a659-0057bf657c2a registered with protocol: quic connIndex-2 ip-22.214.171.124 location=LAX
2023-02-01720:02:55Z INF Connection a26b08b-89ac-47a2-a370-27f9c91bbd registered with protocol: quic connIndex-3 ip-126.96.36.199 location=SEA
2023-02-01T20:03:12Z INF Unregistered tunnel connection connIndex=2
2023-02-01720:03:12Z WRN Failed to serve quic connection error="timeout: no recent network activity" connIndex=2 ip-188.8.131.52
2023-02-01720:03:12Z WRN Serve tunnel error error-"timeout: no recent network activity" connIndex=2 ip-184.108.40.206
2023-02-01720:03:12Z INF Retrying connection in up to 1s connIndex=2 ip=220.127.116.11
2023-02-01720:03:12Z INF Unregistered tunnel connection connIndex-0
2023-02-0120:03:12Z WRN Failed to serve quic connection error="timeout: no recent network activity" connIndex-0 ip-18.104.22.168
2023-02-01720:03:14Z ERR Connection terminated error="timeout: no recent network activity" connIndex=1
There is a HIGH possibility that your ISP *doesn't support this and your tunnel will continue to have these errors. To fix this issue, you need to downgrade the CloudFlared Docker App to:
Any update from
2022.3.4to present-day will result in having a quic protocol connection, not standard HTTP2 protocol connection.
If your ISP *does support the "quic" protocol, feel free to update to the latest version:
If you have finished your Argo Tunnel installation and the configuration process, but are still getting error messages, please look for the solution in one of the following links:
Create a DNS record for the subdomain you want to go to for SSH access. Below is an example
Ingress rules resolve top down, so this rule should be above the - service: https://REVERSEPROXYIP:PORT/ rule.
- hostname: ssh.domain.com
This can be done here, free plan works up to 50 users but needs billing details, you may be able to get it to work with no plan
Add your application for your SSH service and then enable browser based rendering
To list all configured tunnels and see active connections:
docker run -it --rm -v /mnt/user/appdata/cloudflared:/home/nonroot/.cloudflared/ cloudflare/cloudflared:latest tunnel list
NAMEID in hex
NAME of the tunnel
TIMESTAMP Date and time created
To revoke and delete a tunnel:
docker run -it --rm -v /mnt/user/appdata/cloudflared:/home/nonroot/.cloudflared/ cloudflare/cloudflared:latest tunnel delete TUNNELID
If there are still active connections on the tunnel you need to force the deletion. Connections will be dropped:
docker run -it --rm -v /mnt/user/appdata/cloudflared:/home/nonroot/.cloudflared/ cloudflare/cloudflared:latest tunnel delete -f TUNNELID
Deleting the Tunnel also invalidates the credentials file associated with that Tunnel, meaning those connections can not be re-established.
If you have multiple different domains and you want to use the tunnel and Cloudflared container, you only need to copy the
UUID.cfargotunnel.comused for the CNAME across to other domains in Cloudflare.
There is no need to deploy multiple containers of Cloudflared. One container can do multiple domains.
You also do not need to modify your YAML any further. One valid subdomain entry is enough.
If you still decide to run multiple containers (for example, if you wanted redundancy) you can check those connections with command in your Unraid terminal:
docker run -it --rm -v /mnt/user/appdata/cloudflared:/home/nonroot/.cloudflared/ cloudflare/cloudflared:2022.4.0 tunnel info UUID
If you have one container using the single tunnel UUID and one/multiple domains using the single tunnel, you will only get 1 record when using the cli command.
If you have 2+ containers using the single tunnel UUID and one/multiple domains using the single tunnel, you will get a record for each cloudflared container when using the cli command.
IT IS AGAINST CLOUDFLARE TERMS OF SERVICE TO USE PROXYING VIA CLOUDFLARE FOR ANY CONTENT THAT IS NOT HTML TRAFFIC.
THIS INCLUDES THE STREAMING OF MEDIA VIA THEIR NETWORK.
YOU RISK YOUR CLOUDFLARE ACCOUNT BEING BANNED IF YOU DO NOT HEED THIS WARNING!
FOR MORE INFORMATION REFER TO THE OFFICIAL TOS:
SPECIFICALLY SECTION 2.8 Limitation on Serving Non-HTML Content
To safeguard yourself - turn the proxy off on any subdomains which do not use HTML content by changing the cloud icon in DNS to grey (proxy off).
We hope you enjoyed this guide. It was conceptualized, written, and implemented by our community member Aeleos and Community Leader Hawks.
Our work sometimes takes months to research and develop. If you want to help support us please consider: