400: Bad Request error with Unifi Controller

I currently have Caddy setup to serve a few sites, and one of them is my Unifi controller. I had it working, but I recently noticed that it wasn’t working anymore. Whenever I try to load unifi, I get a 400: bad request error.

Here is my section of the Caddyfile in question:

unifi.<mydomain>.net:443 {
    gzip
    proxy / https://<unifi-controller-ip>:8443 {
            insecure_skip_verify
            websocket
            transparent
    }

}

Here is my post in the ubiquiti forums as well: Unifi Controller error with Caddy reverse proxy

Any help is greatly appreciated. Thanks!

I use something incredibly similar.

unifi.example.com {
  proxy / https://unifi:8443 {
    transparent
    websocket
    insecure_skip_verify
  }
}

You mentioned you’re on Controller software v5.10.19 in the linked ubnt community post. I’m using 5.10.19 (Build: atag_5.10.19_11646) as well, via Docker (hence the unifi hostname in my Caddyfile).

While I’m running Caddy 0.11.5 (not 0.11.3 as you stated in the ubnt post), it did work for me on 0.11.0 as well. Try upgrading?

Just to 100% confirm, when you browse manually to https://<unifi-controller-ip>:8443, you don’t have any problems logging in?

I just upgraded to Caddy 0.11.5 per your suggestion. Unfortunately, it’s still not working.

One weird thing is that it works when I use incognito/inprivate mode. I’ve tried to clear my cookies for the site, but it still doesn’t work. I have no idea what’s going on here.

edit: also, yes, I can access it when i browse manually.

Not sure about that.

I’ve been having my Firefox redirect me to File Browser when I browse to localhost:2015 ever since Wed, 04 Apr 2018 04:41:54 GMT when I compiled Caddy with the http.filebrowser plugin to try to troubleshoot a problem someone else was having. Specifically, ever since that day, it redirects to http://localhost:2015/login?redirect=%2Ffiles%2F (and displays a whole page complete with css!).

I’ve cleared the entire cache, history, etc that Firefox will let me clear, to the beginning of time several times since. I’ve since updated Caddy again without Filebrowser, and today it’s not even running on that port. Refreshing the page it got redirected to results in “unable to connect”. Safari is unable to connect. I can’t CURL it. It’s purely Firefox caching a redirect and the contents of that redirect somehow. How? I dunno. Moral of the story is that browsers are weird, try uninstalling / reinstalling or using a different one.

It’s happening on multiple browsers on multiple devices

Ehhh? But it works in incognito? Man, that’s a pretty strange outcome. Does it work incognito on all your devices?

I’ve narrowed it down. I’m only getting the error in Chrome, while I’m not in incognito mode. Firefox is working.

Chrome on my phone and my computer both show the 400: bad request error still though. Could chrome have a bad update right now? or is it something with caddy not working properly with chrome?

edit: definitely only regular chrome. even edge is working. why chrome why

What’s your Chrome version?

I just tested my own setup via Chrome 72.0.3626.121 (Official Build) (64-bit), working well.

Edit: Just updated to 73.0.3683.86 (Official Build) (64-bit). Still good on my end.

Version 72.0.3626.121 is what I’m on now

edit: updated chrome. IT’S FIXED. @Whitestrake, thanks for all of your help and input! I’m on Version 73.0.3683.86 now.

1 Like

I broke it again… @Whitestrake :confused:

So, i tried to add in
basicauth / <user> <pass>
and its giving the error again. I removed the basicauth, but it’s still giving the error for some reason. Why can’t I use basicauth with unifi?

There’s absolutely nothing I can think of that would cause incompatibility between basicauth and the Unifi controller.

The former uses the Authorization header, whereas the controller uses cookies to authenticate you once you’re logged in.

Just tried it myself. Looks like it’s time to eat my words; basicauth broke my controller page.

I’m looking into it.

Thanks again for your help. I’m glad to know it’s not just me.

Follow-up: Based on what I’ve found, I think that if I have basicauth anywhere in my Caddyfile, it breaks unifi. Even if basicauth wasn’t listed under unifi, it was still causing issues. I’m trying to use basicauth for unifi, as well as for some other sites as well. I can live with it if I can’t use it on unifi, but it would really suck to not be able to use basicauth on any other sites served up by Caddy.

Got a fix for the continued issues. Something (the websocket / API?) really hates the Authorization: basic header. Fatal error levels of hate. I had to wipe the last hour of browsing to get Firefox to stop sending the Authorization header entirely.

The issue is that the browser sends the Authorization header automatically for subsequent requests to the same domain. Once I had the browser stop sending that, it was fine.

1 Like

In order to allow chrome to open my unifi controller after removing basicauth, I’m forced to completely relaunch chrome. This is a strange issue.

I’m not sure what’s going on. None of the API requests make use of the Authorization header, but when basicauth is in play, the API requests are the ones returning 400s if you send them that header.

I was wrong about it not working with basicauth anywhere in the file. I think i was running into the issue with the browser sending the header automatically.

To sum up:
basicauth was my issue this entire time. I guess I had only used it in chrome earlier, hence my issue.

Edit: I reached my max amount of posts for the day :confused: I wish it could be increased.

@Whitestrake, this is in reply to your post below.
I’m serving multiple subdomains with caddy.

Also, you’re right. I currently have basicauth working on a different subdomain, just not Unifi.

As long as the basicauth isn’t on the same FQDN as the proxy to the Unifi controller, your browser shouldn’t be conflating the two and sending Authorization where it isn’t meant to be sent. Your redacted site address has a unifi. subdomain, is that accurate? Is there a basicauth on another site label with that subdomain specifically, or just on the main domain?

Ran out of replies last night since I only created my account yesterday.

Any chance of a fix for basicauth with the controller? I have no idea if it’s on the side of caddy or unifi.