Redirect to wrong proxy


(curious learn) #1

I am using Caddy as a reverse proxy. My caddy file has directives like the following. The problem: when some of my users visit othersite.mydomain.com, they get redirected to site1.mydomain.com. Any ideas why this may be happening? I don’t even know where to look to get this fixed. Would really appreciate any pointers.

Thank you very much.

site1.mydomain.com {
	proxy / localhost:15000 {
		transparent
		websocket
	}
}


othersite.mydomain.com {
	proxy / localhost:17000 {
		transparent
		websocket
	}
}

(Matt Holt) #2

Can you please put your entire, unmodified (including domain names and addresses) Caddyfile here? You can’t hide anything anyway since it’s in CT logs. If you changed anything from how it is when you posted it here, it’s impossible to know what is causing it.

Also the exact command you use to run Caddy please.


(Matthew Fay) #3

No. Nothing in the configuration you posted will cause either site to redirect to the other, and without knowing your real domain name, we can’t investigate further.


(curious learn) #4

I am sorry but I do not follow when you mean when you say that “I cannot hide anything.” It would be great if I could email the Caddyfile to you and Whitestrake. I don’t feel comfortable posting it here in public. I would appreciate if that is possible.

Regarding how I start Caddy, I use systemd to do that. Below is my complete configuration file that starts the caddy service. I have also enabled this service so that Caddy starts automatically on startup.

To clarify, I have not been able to reproduce the issue. But some people of my users claim it is happening to them. Could it have to do with their browser cache? Do browsers redirect to different subdomains for any reason?

Thank you very much for responding, and for creating awesome Caddy.

[Unit]
Description=Caddy server
After=network.target rethinkdb.service

[Service]
Type=simple
LimitNOFILE=8192
ExecStart=/usr/local/bin/caddy -conf="/home/myusername/Caddyfile" -agree -email="myuser.name@gmail.com"
StandardOutput=file:/home/myusername/logfiles/caddyservice.log
StandardError=file:/home/myusername/logfiles/caddyservice.log
Restart=always
RestartSec=10

[Install]
WantedBy=multi-user.target


(Matt Holt) #5

We can definitely help in private if you are a paying customer, but I can’t afford to help in private for free. Do you have a support plan with us? If not, I can get you set up. The reason we need the actual file contents is because if the contents change, we can’t assess what is causing the problem, since the parts that get changed are often factors.


(Matthew Fay) #6

To clarify, this comes up as people regularly state that they redact their domain names out of fear of those domains becoming public knowledge. Certificate Transparency logs mean that your domain, and the fact that you were given an SSL certificate for it, is already public knowledge.

Hasty or improper redaction also causes some problems. For one example, you’ve changed your domain name to othersite.mydomain.com, but did you know that’s actually someone else’s domain you’re now using in your request for help? https://www.mydomain.com/ is actually a domain registrar, and it looks like they serve their site with Apache. Also, did you consider that someone else might actually control the myuser.name@gmail.com Gmail account?

The Internet Assigned Numbers Authority (IANA) actually reserve a few domains for this purpose; example.com and example.org. You can use these for illustrative examples and documentation without having the real owner pop up in this thread after searching the internet for their own domain name or discovering referred traffic from people browsing to their site (as we’ve had in the past, believe it or not).

But the main issue is this:

The wording here is a fairly direct implication that the config you’ve posted is not actually what you’re using. Small details matter a lot; the exact specifics of your actual, in-use Caddyfile are where the real issue arises in the vast majority of cases.

Based on what you have provided, the only information we (or anyone) could give is that the configuration you gave is not designed to produce any redirects (other than upgrading HTTP to HTTPS) and that there are no known bugs that might cause it to do so.

Have you ever redirected between these sites in the past?

Generally speaking, browsers will remember redirects for a(n annoyingly) long time, but they won’t ever produce a (seemingly random) redirect like that.


How to get help with Caddy more effectively
(Matt Holt) #7

Summed it up quite nicely there, @Whitestrake! (I’m gonna get slightly OT here but don’t mind me.)

This is true – and I also always recommend using these domains for examples – but even changing the domains in one’s pasted Caddyfile to these official example names can cause delays when trying to diagnose problems, because knowing the exact names is often relevant; for example, whether they are subdomains of each other, how many different domains we’re dealing with, etc, etc. There are only 2 example names, and we can’t lose this information when debugging people’s Caddyfiles.

This :100: %

Thanks for clarifying this in a way I could not so easily myself, I will see if we can add this to an FAQ, or the docs, or some forum helper page or something. Maybe even the issue template.


(curious learn) #8

First, apologies to everyone for using the domain names owned by others.

Second, thank you so much again for taking time to respond.

Regarding the issue itself, I agree that I should have been clearer. Sorry about that. When I said that my

Caddy file has directives like the following

the only difference is in the domain names and the number of subdomains I have. Other than that the actual directives are exactly the same as I reproduced.
I had no redirects between these in the past. The only thing I can think of is that I may have used the same port, and that these users use and have used both the subdomains (which are two independent applications). One of the subdomains was newly introduced. From your responses, and my inability to duplicate the problem it appears to me that either my users were doing something wrong, or their browsers are saving some information that is causing this problem.

Just for record this is my complete Caddyfile with only the domain names and subdomain names changed. The number of entries is the same as in my actual file.

I really appreciate both your help. I don’t expect any more responses on this. Thank you very much once again for your inputs. I will wait to see if any more users complain about the redirect. If they do, I will come back here again.

phys.example.com {
	proxy / localhost:15000 {
		transparent
		websocket
	}
}

static.example.com {
	root /home/example/web/static
}



efg.example.com {
	proxy / localhost:9000 {
		transparent
		websocket
	}
}

abc.example.com {
	proxy / localhost:17000 {
		transparent
		websocket
	}
}


ssg.example.org {
	proxy / localhost:30000 {
		websocket
		transparent
	}
}

subdomain.example.org {
	root /home/example/subdomain
	fastcgi / /var/run/php/php7.2-fpm.sock {
		ext .php
		split .php
		index index.php
	}
}