The server says online, but the page won't load. Nine times out of ten it's one of the checks below — work down the list in order and you'll find it.
1. Are you visiting the right address?
Your public address isn't a guess — it's printed on the Network page, under the Ports tab: an IP or hostname plus a port number. Use exactly that address:port. A plain http://address:port link always works with no extra setup. (If you've set up a domain or reverse proxy, that's a different URL — see Domains and HTTPS.)
⚠️ Heads up: On a raw
address:port, typehttp://, nothttps://. A bare port has no SSL certificate, sohttps://just refuses to connect. HTTPS comes only from a reverse-proxy domain (step 5).
2. Does your app read SERVER_PORT?
Falix gives your server one public port and hands it to you as the SERVER_PORT environment variable. Your app has to listen on that port. A hard-coded number like 3000 is the classic "works on my PC, not on the server" bug — the outside world can't reach it. Read the port from the environment:
// Node
const PORT = process.env.SERVER_PORT || 8080;
server.listen(PORT, '0.0.0.0', () => {
console.log(`Listening on port ${PORT}`);
});
# Python (Flask)
import os
app.run(host="0.0.0.0", port=int(os.environ["SERVER_PORT"]))
3. Does it bind 0.0.0.0, not localhost?
Notice the 0.0.0.0 in both snippets. Binding to localhost (or 127.0.0.1) means "only accept connections from inside this container" — so your app works from its own point of view but is invisible from outside. Binding 0.0.0.0 means "accept connections on every address", which is what you want. This is the other half of the same classic bug, and just as common as the port one.
4. Is it actually a website?
🎯 Good to know: A pure Discord bot has nothing to visit — it makes an outgoing connection to Discord and never listens for incoming traffic, so there's no page and no port to open (
SERVER_PORTis irrelevant to it).
If you were expecting a web page from a bot, that's the mix-up. (A bot that also runs a small web dashboard is a different story — then it does listen, and rules 2 and 3 apply to that part.)
5. Using a reverse proxy? Check the backend port
If you've put a domain in front of your app with the Reverse Proxy tab on the Network page, the backend port it points at must be one of your server's own ports (in the 1024–65535 range) — the same port your app is actually listening on. Point it anywhere else and the proxy has nothing to talk to. If the domain still won't load over https://, check its SSL status on that tab shows active, not pending — a freshly added domain won't serve until the certificate finishes.
6. Is your app even listening?
Back to the Console. A web app that started correctly prints a line telling you it's up — something like Listening on port 25565. If you never see a line like that, your app isn't listening yet, and the problem is earlier: it probably crashed or exited during startup. Read the console from the top — When your server won't start covers that.
💡 Tip: For Node apps, that
Listeningline is also what flips the panel's status to online, so it does double duty.
7. Listening, but still unreachable? Check the Firewall
If the console shows your app listening on the right port but the outside world still can't connect, the last thing to check is the Firewall page. Most servers never touch it — but if you enabled it and added a Drop rule, it can silently block the port you're serving or the address you're connecting from. The page's traffic analytics show a blocked count, which is a quick way to confirm whether the firewall is eating your requests.