Add-On doesen’t recognize internal URLs behind reverse proxy?

We have an enterprise on premise instance and I have noticed, that the browser addon doesen’t recognize certain websites even though the URL is correct in the entry.

I even tried the option autofill and save, and while this does actually save the entry the URL still isn’t recognized and hence it isn’t offered as a valid login for the site. I have to search the entry by hand and select it.

Example - Gitlab (internal domain):

Version: 2022.8.1

I have never heard of this being an issue. I wonder if something needs tweaking with your URI Matching rules? What is your Default URI Match Detection set to in your Bitwarden options?

Hey, sorry for the late reply.

Do you mean the personal user settings? I didn’t change anything there and the affected entries itself are also set to default matching.

If default matching is too restrictive, that would explain this behaviour then.

In the browser extension, go to Settings > Options. What is the setting that has been selected for the default method for URI match detection? (Standard Übereinstimmungserkennung)

It’s set to default, which is “begins with”.

Well, default is set to “begins with…” and the URL actually begins with exactly that

Nontheless, I tried autofill and save, which added the exact url to the entrie, but it still doesen’t recognize the login form.

So, definitely some kind of bug right here.

Does the domain name contain any non-ASCII characters (e.g., umlauts)?


I also updated to Version 2022.10.0, tried different clients, other login forms.

I can’t pinpoint anything special to those affected sites/forms compared to the other ones that work without problems.

But I’ve noticed that only internal sites that aren’t public are affected.

Strange. Just a random idea: if those internal domains have static IP addresses on your internal network, trying adding the IP address as an additional URI.

They are all behind internal reverse proxies (apache or nginx).

I just noticed that your URI starts with http instead of https. Is this really correct for your environment ?

Yes this is correct, gitlab (now using gitea) is one of the few applications that are not behind the reverse proxy. What’s interesting though, is that if I use the IP to access these internal applications, bitwarden recognizes the host credentials correctly!

I reproduced this with gitea and another application. So it has to be some issue with the bitwarden extension not being able to lookup the local DNS from the machine/browser. The DNS is configured on the docker host where bitwarden is located and I can nslookup gitea without problems.

Can anyone else test/confirm/reproduce this on their internal sites?

I think Peter may be onto something that would be worth testing further. Can you test what happens if you change the stored URI from http:gitlab... https:gitlab...? If your server is not using SSL, the browser should redirect to the http: page, but perhaps this will help Bitwarden recognize the URL?

Another option to try: Use Host or Regexp options for the URI matching (instead of your default Begins With).

Just tested setting the URLS form http to https, didn’t solve anything.

I will try the Regex solution on monday.

Very late update, but I tried regex with ^gitlab$ and host, same thing, the url is not recognized.

Smells like a bug to me.

Can you provide a little more information? For example, what is the domain name suffix? My understanding is that there may be issues with URI matching if the domain suffix is not on the public suffix list.

Also, it may be a good idea to let us know more about your environment (OS, browser, etc.).

The suffix is not included in this list.

I have an AIO selfhosted installation (on debian bullseye) and I just updated everything to the latest 2022.12 version:


Server Installed 2022.12.0
Web Installed 2022.12.0

I doubt it’s related to the browser, since I have installed Chrome v108 and the issue is present on any other client I’ve tested this.

Does URL matching work if you set your matching rule to Host or Domain?

Hey, as mentioned earlier, no. The only thing that works for our internal domain are http/s URLs with IPs (such as