38
Port forwarding & reverse proxying question.
(sh.itjust.works)
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
this post was submitted on 14 Apr 2025
38 points (97.5% liked)
Selfhosted
49821 readers
61 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.
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
There's not really enough to give an conclusive answer from "it's not reachable". All I can do is tell you what I'd probably do to try to troubleshoot further.
My first steps in troubleshooting connectivity would probably be something like this:
Fire up something on the HTTP server (I'm assuming it's running Linux) like
sudo tcpdump port 80. That should let you see any packets that are reaching the HTTP server.From a Linux machine on an outside network
a tethered cell phone might make a reasonable machine, if you don't have another machine you control out there somewhere in the ether
running something like
mtr --tcp -P 80 <hostname>. That'll tell you, at an IP-hop-by-IP-hop level, whether there's anything obstructing reaching the machine. Could be that your ISP blocks 80 inbound, for example.curl --verbose http://<hostname>/. That'll let you see what's happening at the HTTP level.I'm guessing that you're probably going to have something along here break. It could be that the packets are being blackholed at a hop prior reaching your router, in which case your ISP may be firewalling inbound on that port. It may be that they're reaching your router, but that your router is trying to forward to the wrong machine. It may be that you have some kind of firewall on the HTTP server that's blocking connections that aren't coming locally or from the WireGuard side. But at least it'll probably give you a better idea as to how far it's getting.
Once you've got that up and running, can look at HTTPS:
If this is working, if you want to test the TLS certificate handshaking, see if there are any issues, again, from an outside network:
openssl s_client -connect <hostname>:443 -prexit. That'll let you see the TLS handshake and any issues that happen during it.Also from an outside network, running
curl --verbose https://<hostname>/. That'll let you see what's happening at the HTTPS level.EDIT: Oh, yeah, and someone else pointing out confirming that the DNS resolution is what you expect is probably also a good first step.
host <hostname>from an outside network.