What I’m trying to do;
Setup a basic caddyserver configuration to handle the reverse proxy of three domain names along with having a static content be directed at if someone attempts to connect directly to the IP address of the machine.
Such as;
##.##.##.## > Redirect to static_html for a basic index domain1.com > Proxy data to port 7050 so a local Golang server can handle it domain2.com > Proxy data to port 7075 so a local Golang server can handle it domain3.com > Proxy data to port 7100 so a local Golang server can handle it
What I’ve tried;
Running ./caddy with the config file called “Caddyfile” in the same directly as caddy itself with the following content;
http://deleted.com {
tls off
proxy / localhost:7050
}
http://deleted.party {
tls off
proxy / localhost:7075
}
http://deleted.pw {
tls off
proxy / localhost:7100
}
But for some reason connecting directly to host gives me “No such site at :80” along with connecting to any of the domains gives the standard “took too long to respond” error message.
I don’t know why it’s not working and the there are no logs generated except from these;
system@Golang_Server_Test:~/caddyserver$ sudo ./caddy
[sudo] password for system:
Activating privacy features… done. http://localhost
http://.com
http://.party
http://**.pw
WARNING: File descriptor limit 1024 is too low for production servers. At least 8192 is recommended. Fix with “ulimit -n 8192”.
--------
Edit; Solved at the bottom, looks to have been me forgetting about how long DNS can take sometimes or maybe a bad reverse config/https config.
Added it and it still gives me “No such site at :80” connecting directly to with still no logs on why it’s failing to connect redirect the traffic.
I’ve even resorted to using a very basic html webserver for all the domains in Golang to see if it could possibly be a issue with the sites somehow and yet they also don’t work.
package main
import (
"fmt"
"html"
"log"
"net/http"
)
func main() {
http.HandleFunc("/", func(w http.ResponseWriter, r *http.Request) {
fmt.Fprintf(w, "Hello, %q", html.EscapeString(r.URL.Path))
})
http.HandleFunc("/hi", func(w http.ResponseWriter, r *http.Request){
fmt.Fprintf(w, "This should work on all domains")
})
log.Fatal(http.ListenAndServe(":7050", nil))
}
Removing the http:// makes all the default ports become 2015, doesn’t really work at all.
Firewall has nothing on the client and the global default firewall for machines by the host are;
TCP & UDP port 17
TCP & UDP port 19
TCP & UDP port 1900
For how easy this is suppose to be to use it appears to have zero friendly error/suggestions on why its not working. Nginx works perfectly fine so probably will end up going back to it rather then spending hours trying to figure out why this “easier solution” doesn’t work.
Although I can’t explain why isn’t working for you, the setup is pretty dumb proof. I am doing similarly to you (granted, I am using 80 and 443), and it “just works.” Like so:
git.quark.business {
log /var/log/caddy/git-quark-business.log {
rotate {
size 5 # Rotate after 5 MB
age 30 # Keep log files for 30 days
keep 2 # Keep at most 2 log files
}
}
tls {
key_type rsa4096
}
proxy / http://127.0.0.1:3000 {
transparent
}
}
It might be cause I got a corrupted download/build perhaps because I’m no longer able to redownload @ Download Caddy without it giving me; “Error: Sorry about that. You can try again or download Caddy core from our backup site (without any extra features).”
It’s almost impossible to help when you’ve redacted your Caddyfile. Domain names aren’t secret, you know.
But this error is not hard to fix. It happens when Caddy gets a request for a hostname it is not configured to serve. Make sure the Host in the request is one of the sites you’ve added to your Caddyfile.
I got it working for some reason the DNS for my domain names took over 12 hours to change and I was use to them changing within a few minutes. Or might of been a issue with it trying to validate the HTTPS and failing some reason.
Wrote a super easy guide for Vultr users in the future if it gets accepted for setting up a Golang application and using caddy for reverse proxy/load balance it.
@Gabbino fyi, for the future make sure you lower your DNS TTL well ahead of a planned record change. 86400 is not uncommon depending on your provider. Another strategy is to run old and new server in parallel for a period of time to allow the TTL to expire on caching resolvers across the Internet
