A hobbyist with a spare Raspberry Pi and a free weekend decided to host his own website from the spare room. He installed a web server, wrote a few pages about restoring old radios, bought a cheap domain, and pointed it at the address his router showed on its status page. He opened a port on the router, typed the domain into his phone on mobile data, and the page appeared. For three weeks it was the most satisfying thing he had built in years.
Then one morning the site was gone. The Pi was running, the web server was up, and the domain still existed. From the outside, though, the page timed out. This is a fictional composite, but the failure is one of the classic ones for anyone hosting from home.
What follows is how the problem works, how he found it, and the options he weighed before moving the site somewhere that does not depend on a domestic internet connection.
What he had built
The setup was sound in its basic parts. A Pi on the home network ran a web server on port 80 and later 443. The router forwarded those ports to the Pi's local address, something like 192.168.1.50. The domain's A record pointed at the router's public address. When a visitor typed the domain, DNS returned that address, the request arrived at the router, and the router handed it on to the Pi.
The morning it vanished
He noticed because a friend messaged to say the site was down. His first check was the obvious one: the Pi answered locally. Opening http://192.168.1.50/ from his laptop showed the page, and the server logs showed no errors. He restarted the web server anyway, which changed nothing.
Next he looked at DNS. A quick lookup showed the record was exactly as he had left it:
$ dig +short example.com A
203.0.113.20Then he looked at what the router now reported as its public address. It said 203.0.113.87. The internet provider had handed his connection a new address, probably after a router restart overnight or a short outage in the area. DNS was still pointing at 203.0.113.20, which now belonged to another customer, or to nobody at all. Visitors were knocking on the wrong door.
Why home connections change address
Most residential broadband uses dynamic addressing. The provider owns a pool of public addresses and lends them out to connections for a period, called a lease. The lease may be renewed for months, or it may end when the router restarts, when the line drops and reconnects, or when the provider reorganises its network. From the customer's side the change happens without any notice.
Some providers keep the same address for years in practice, which is why the first three weeks went smoothly. Others rotate daily. Neither behaviour is a fault, and it is not something his provider would normally fix on request. Static addresses exist, usually as a paid add-on or a business tariff.
There are two further complications worth knowing. Some providers put customers behind carrier-grade NAT, where many homes share one public address and no inbound port forwarding is possible at all. And IPv6 changes things differently: a home may have a stable-looking prefix that still changes when the provider renumbers.
Dynamic DNS: the first fix
The standard repair is a dynamic DNS client. A small program on the Pi, or on the router if it supports one, checks the public address every few minutes. When the address changes, it sends an authenticated update to the DNS provider, which rewrites the A record. The record then follows the connection around.
He set it up in an evening. The steps were roughly these:
- Create an API token at the DNS provider that is allowed to edit only that one record.
- Install a dynamic DNS client on the Pi, or write a short script that asks an address-echo service for the current address and calls the provider's update API.
- Set the record's TTL low, around 300 seconds, so resolvers forget the old answer quickly. The TTL planner shows the trade-offs.
- Run the client from cron every five minutes, for example
*/5 * * * * /usr/local/bin/ddns-update, and write the result to a log file. - Test it: restart the router, wait, and watch the record change with
dig.
The worst case is the sum of two delays: the time until the client next checks, plus the time old answers survive in caches. With five-minute values for both, expect up to ten minutes of downtime after each change. For a radio-restoration hobby page, that was acceptable.
The other problems that stayed
Dynamic DNS solved the address and nothing else. Over the next two months he ran into the remaining limits of hosting from a bedroom, and each one was a reasonable argument for leaving.
- A power cut in the street took the site down for three hours, and the Pi's SD card was corrupted by an unclean shutdown on another occasion.
- Upload speed on home broadband is typically a fraction of download speed, so a page with large images was slow for anyone not on his street.
- Opening ports at home exposes every device behind that router to scanning. He had to keep the Pi patched and put a firewall in front of it.
- Some providers prohibit running servers on residential plans, or block port 25 and sometimes 80, in their terms.
- No one could reach the site if he rebooted the router to fix something unrelated.
None of these is a catastrophe for a hobby page. Together, they meant that every small event at home was now a public outage.
Moving to a small hosted server
He moved the site to a small hosted server, a modest virtual server in a data centre. The move was uneventful and follows the usual pattern: copy the files, set up the web server and certificate, test using a hosts-file entry, lower the TTL a day before, change the A record, and leave the Pi serving as a fallback for a few days. The certificate expiry checker was useful for confirming the new certificate was in place.
The Pi kept a job: running a test copy of the site and some other projects on the home network, where an address change does not matter. That is arguably the right use for it. A home server is a good place to learn, to build and to host things only you need to reach.
| Where it runs | Address stability | Power and network | Good for |
|---|---|---|---|
| Pi at home, record by hand | Changes without warning | Domestic | Nothing public |
| Pi at home with dynamic DNS | Follows within minutes | Domestic | Hobby pages, personal tools |
| Small hosted server | Fixed | Data centre | Any public site |
| Shared hosting | Fixed, managed for you | Data centre | Simple sites with no admin |
Look at your own configuration
Compare two numbers. What does DNS say, and what does your connection say? Run dig +short example.com A and then ask an address-echo service for your current address, for instance with curl -s https://ifconfig.me. If they differ, that is your outage. Do the same for IPv6 with dig +short example.com AAAA, because a stale AAAA record can break the site for visitors who prefer IPv6 even when the A record is right.
Also look at the router's WAN address page. If it shows an address starting 100.64 to 100.127, or a private range, you are behind carrier-grade NAT and port forwarding will not work at all. The DNS cheatsheet lists the record types and the dig options used here.
Questions that come up
Can I just ask my provider for a fixed address?
Often, yes, usually for a monthly fee or on a business tariff. It solves the address problem and none of the power, speed or security ones.
Does a low TTL cause problems?
It means more lookups against your DNS provider, which is harmless at hobby scale. Raise it again once the site lives somewhere stable.
Is it safe to expose a Pi to the internet?
It can be, with automatic security updates, no default passwords, key-only SSH logins, and only the necessary ports open. Many people prefer a tunnel service that avoids opening ports at all.
Why did the page work on his phone's mobile data but not from home?
Many routers cannot loop a request for their own public address back inside the network. Test from outside, as he did, not from the same Wi-Fi.
What stayed with them
A DNS record that points at a home connection is only as reliable as the lease behind it. Dynamic DNS shortens the outage, a hosted server removes it, and the Pi remains an excellent machine for everything that does not have to be public.