Caddy reverse proxy always redirecting to localhost

Support
1

Hi, I’ve been trying to setup SyncThing on my home server and I’m trying to put it behind a reverse proxy (Caddy).

What’s happening is that when I get to the endpoint, it redirects to “https://localhost:8384/”, making it unusable (even if I change the listener to 0.0.0.0:8384) trying to access it on a machine that isn’t the server.

This is my entire Caddy config right now:

{
    debug
}

a.b.xyz {
    root * /var/www/html/
    file_server

    rewrite /filebrowser /filebrowser/
    handle_path /filebrowser/* {
        reverse_proxy localhost:8080
    }

    rewrite /syncthing /syncthing/
    handle_path /syncthing/* {
        reverse_proxy localhost:8384 {
            header_up Host {upstream_hostport}
        }
    }
}

For Syncthing, I put on TLS and an HTTP GUI account (for auth).

I’d appreciate any help on this. It seems that no one else is really running into this issue so past forum posts haven’t really helped :pensive:

Caddy Log on Request 
{
	"level": "info",
	"ts": 1735855782.0329304,
	"logger": "http.log.access.root",
	"msg": "handled request",
	"request": {
		"remote_ip": "1.1.1.199",
		"remote_port": "61469",
		"client_ip": "1.1.1.199",
		"proto": "HTTP/3.0",
		"method": "GET",
		"host": "a.b.xyz",
		"uri": "/syncthing",
		"headers": {
			"Accept-Language": [
				"en-US,en;q=0.9,vi-VN;q=0.8,vi;q=0.7"
			],
			"Priority": [
				"u=0, i"
			],
			"Sec-Ch-Ua-Mobile": [
				"?0"
			],
			"User-Agent": [
				"Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/131.0.0.0 Safari/537.36"
			],
			"Sec-Fetch-Site": [
				"none"
			],
			"Sec-Fetch-Dest": [
				"document"
			],
			"Upgrade-Insecure-Requests": [
				"1"
			],
			"Accept": [
				"text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.7"
			],
			"Sec-Fetch-User": [
				"?1"
			],
			"Sec-Ch-Ua": [
				"\"Google Chrome\";v=\"131\", \"Chromium\";v=\"131\", \"Not_A Brand\";v=\"24\""
			],
			"Sec-Ch-Ua-Platform": [
				"\"Windows\""
			],
			"Sec-Fetch-Mode": [
				"navigate"
			],
			"Accept-Encoding": [
				"gzip, deflate, br, zstd"
			]
		},
		"tls": {
			"resumed": false,
			"version": 772,
			"cipher_suite": 4865,
			"proto": "h3",
			"server_name": "a.b.xyz"
		}
	},
	"bytes_read": 0,
	"user_id": "",
	"duration": 0.002750977,
	"size": 59,
	"status": 307,
	"resp_headers": {
		"Content-Length": [
			"59"
		],
		"Content-Type": [
			"text/html; charset=utf-8"
		],
		"Server": [
			"Caddy"
		],
		"Location": [
			"https://localhost:8384/"
		],
		"X-Content-Type-Options": [
			"nosniff"
		],
		"X-Frame-Options": [
			"SAMEORIGIN"
		],
		"X-Xss-Protection": [
			"1; mode=block"
		],
		"Date": [
			"Thu, 02 Jan 2025 22:09:42 GMT"
		]
	}
}
2

Don’t do that. The request on the inside of Caddy will be plain HTTP, causing the redirect you see.

1 Like
3

Thanks for the help, it stopped redirecting to localhost! I’m guessing the use TLS causes Syncthing to autoredirect when it’s forwarded the http request from the proxy?

However it seems I’m having another problem with the site displaying like this:

{47F99062-E602-4B0C-809D-84EFCEB8E17A}
{47F99062-E602-4B0C-809D-84EFCEB8E17A}1870×848 55.1 KB

Do you have any ideas as to why this is happening?

4

Update on that last comment: Adding a trailing slash makes it work. I’m glad it works now but do you know why the trailing slash is necessary? If not, thanks for the help! Appreciate it a lot

5

Yeah, a trailing slash will likely be required as the GUI uses relative URLs that won’t make sense to the browser otherwise. Better make the proxy redirect /syncthing to /syncthing/ if you don’t want to do that manually.

(Rewrite is not redirect here, I believe.)

1 Like
6

Thank you so much for the help and the awesome software! I think that’s all I had and so I’ll close out the issue

1 Like