Origin Rule Limited to 8080 and 80
Hello! I have an origin rule that is pointing to my backend server that is listening on port 8080 and 80. However, if I try any other ports, it just refuses to connect. How do I allow more ports? It's a python backend (flask web app on Ubuntu Linux) if that matters.
Thanks!
50 Replies
I'm basically using the Origin Rule as a reverse proxy from a IPv4 numeric IP to a simple api domain name
I know it's possible to allow more ports, another machine of mine has no issues, but I can't remember what I did or if I did anything at all, so I would love a bit of help so I can document it for future reference 😄
There's no such limitation. How exactly did you try to connect?
Using any port besides 8080 or 80 doesn't work
I've tried literally everything, all other ports are accessible on any computer through the http://129.123.153.13:XXXX IP, just not when I do an origin rule
ufw on the linux machine is disabled too, all ports should be accessible
bump - would anyone know what else to try?
@Chaika I think you helped me with something kinda similar many months ago, I highly apologize for pinging, but it's slightly urgent (for a final project due tomorrow hahaha)
using any port other then 8080/80 when connecting to cf?
Eitherway if your origin is insecure/http, your best bet is just to deploy a Cloudflare tunnel on it, making everything secure and just work
When I setup an origin rule on let's say 25578, it fails to connect through the domain name (error 522)
I'm hesitant on doing a tunnel because other classes will be using this machine and I'm unsure if it'll mess with them
Your origin is insecure/only http?
how would I tell?
i'm very new to most of this hahaha
if you didn't setup any certificates for it
do you have the origin rule active right now, to force to 25578?
then it's probably insecure, i can set up some
no, I don't have the origin rule for 25578 right now, that was just an example
I can get a python web server running and test it though
done
wildcard isn't going to match, switch to equals
http://129.123.153.13:25578/
This isn't accessible externally
oh yeah it's not working right now erm
worth noting in some setups, it may work on the external address when you're inside of the network due to hairpinning, but not work truly external
that's fair
let me check my router settings stuff
Tunnels get rid of all this silliness with port forwarding and such
oh weird yeah, it is only accessible through the university vpn
hmmm
yea, big difference between
inside network request -> hits first router which knows its handling the subnet -> gets turned around (hairpinning)
External request -> hits router from outside (firewall, port forwarding, could be double nat/behind two routers, etc)
gonna quickly reboot the machine and see if the changes i did to the router stuff worked
if not, then i might need some help setting up a tunnel haha
Tunnels are super easy, espec if on linux
yeah it is
weird, okay yeah i'll need help setting up the tunnel
literally everything is enabled through the university router settings portal thing
might have to contact IT on Monday and see what's up lol
Sure, this is all within the Zero trust dashboard (left option when account level)
There's a decent guide for getting the base tunnel setup here first: https://developers.cloudflare.com/cloudflare-one/connections/connect-networks/get-started/create-remote-tunnel/
Once you have it installed, you'll want to make a public hostname with the service url of
http://129.123.153.13:25578/
If there's anything in specific that confuses you feel free to ask, otherwise it's pretty simpleCloudflare Docs
Create a tunnel (dashboard) · Cloudflare Zero Trust docs
Follow this step-by-step guide to create your first remotely-managed tunnel using Zero Trust.
Is there a way to have basically all ports exposed so I don't have to create multiple public hostnames?
no, public hostnames are basically per service/dest port
Fundementally Cloudflare's cdn/proxy only has a handful of https ports (443, 2053, 2083, 2087, 2096, 8443), you could never directly expose sssapi.ticketsx.xyz:25578 with proxy enabled
Tunnels make it so https://sssapi.ticketsx.xyz (if not port specified https defaults to 443) -> tunnel -> locally requests 25578
is that right?
Is your service locally (on vpn) reachable via
http://129.123.153.13:80/?yep
then yea, that looks right
does it sometimes take a minute to work?
https://ssapi.ticketsx.xyz/ doesn't seem to be working quite yet
https://ssapi.ticketsx.xyz/ loads for me
ah probably cached lol
it is a blank page tho
so weird
dns cache, most likely
ah yep, works on my phone
awesome
async function getMapboxToken() {
try {
//const response = await fetch(
https://sapi.ticketsx.xyz/api/mapbox-token);
const response = await fetch(http://localhost:8080/api/mapbox-token);
your code's trying to fetch localhost lol, fails to load mapyeah oops
should be good now :D
💀
if i disconnect from the university vpn, it works fine
weird
probably forces university dns which has it cached because you visited it just a bit too eagerly
fair fair
thank you so very much for your help ❤️
I'll contact the IT department for my university (even though I'm one of the student techs and should probably know this) and try and get it figured out 😂
Sure, tunnels just make all this stuff easy. People use them in prod for big sites, completely get rid of the certificate and port forwarding/nat challenges
that's fair, i suppose we can just leave it like this then
that's amazing, this'll actually be really useful
I'd still recommend to use https with the tunnel or you're stuck with http1 instead of http2. Tunnels sadly don't support h2c.
eh I don't think http2 provides very much benefit when connecting to a service on the same machine
https://byroot.github.io/ruby/performance/2025/02/24/http2-past-the-load-balancer.html
byroot’s blog
There Isn’t Much Point to HTTP/2 Past The Load Balancer
I want to write a post about Pitchfork, explaining where it comes from, why it is like it is, and how I see its future. But before I can get to that, I think I need to share my mental model on a few things, in this case, HTTP/2.