In addition to a reverse proxy with mandatory TLS and some IP filtering, I have headscale running on a sub domain (subdomain dns is a wildcard). The main domain is a different, static web page, so anyone scanning IPs for headscale wont see its a headscale machines unless they can guess the subdomain. I figure that might be useful in case theres a zero day that pops up. It just looks like a regular web server to drive-by script kiddies.
this post was submitted on 19 Oct 2025
23 points (96.0% liked)
Selfhosted
53386 readers
64 users here now
A place to share alternatives to popular online services that can be self-hosted without giving up privacy or locking you into a service you don't control.
Rules:
-
Be civil: we're here to support and learn from one another. Insults won't be tolerated. Flame wars are frowned upon.
-
No spam posting.
-
Posts have to be centered around self-hosting. There are other communities for discussing hardware or home computing. If it's not obvious why your post topic revolves around selfhosting, please include details to make it clear.
-
Don't duplicate the full text of your blog or github here. Just post the link for folks to click.
-
Submission headline should match the article title (don’t cherry-pick information from the title to fit your agenda).
-
No trolling.
-
No low-effort posts. This is subjective and will largely be determined by the community member reports.
Resources:
- selfh.st Newsletter and index of selfhosted software and apps
- awesome-selfhosted software
- awesome-sysadmin resources
- Self-Hosted Podcast from Jupiter Broadcasting
Any issues on the community? Report it using the report flag.
Questions? DM the mods!
founded 2 years ago
MODERATORS
That will work as long as your tls certificate is a wildcard cert (of the parent domain), otherwise your subdomains can be found via their certificate records. You probably know this, but caught me out initially, so figured I'll mention it.
Absolutely! I should have said both the dns and certificate are subdomain wildcards. Thanks for clarifying.
Look at either putting it behind a reverse proxy or using the built in Let's Encrypt / ACME configuration.
Suggested documentation:
The config linked to in their documentation states
# Address to listen to / bind to on the server
#
# For production:
# listen_addr: 0.0.0.0:8080
listen_addr: 127.0.0.1:8080
# Address to listen to /metrics and /debug, you may want
# to keep this endpoint private to your internal network
metrics_listen_addr: 127.0.0.1:9090
Port 8080 TCP is used for the connection, 9090 TCP is for metrics and not suggested to port forward. If you use a reverse proxy, you do not need to port forward to either of those ports directly, and instead to the reverse proxy.
Thanks. enabled the acme service thingy in the config file. Took me some tries before I understood I had to add port 80:80 from the docker yaml in order for headscale to setup the certificate. I guess I need to keep forwarding both 8080 for Headscale and 80 for certificate renewal.
should I, or is there a reason, to setup fail2ban too?
Next one is the derp server… but that may be out of reach with my knowledge 😅
The headscale integrated one is mostly enough, you can choose to include the tailscale official ones with their URL as well.