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

If you read this comment on GitHub Issue #1509, as well as the discussion that follows, it seems that Bitwarden’s domain matching algorithms only allow domains that have suffixes in the Public Suffix list.

Since it is possible to match on the IP address — would this not be an acceptable work-around for you?

Pinging @cksapp, since he has some experience with internal domains.

I think @grb is correct then - if you are making up your own domain name instead of using a domain with a recognized public suffix, Bitwarden cannot parse it for a match. My recommendation is to contact Bitwarden support to see if they are aware of a workaround or if they have any plans to change their matching algorithm.

No, because we have several applications running behind two load balancers and two reverse proxies.

I just wrote a mail to support, in hopes of finding a solution (among other authentication issues that have suddenly appeared in the last days).

Thanks for the ping, I actually had this post bookmarked for review later on so this helped bring it to my forefront.

Unfortunately I’ve never come across this issue similarly within my internal networks. My home network is using a personal valid domain.tld and all internal devices have linked hostnames for my internal subdomain. Our work’s network is a .local which as it appears in the linked

seems to be a valid public suffix per the comment

jamescridland commented on Oct 31, 2021

Good catch.

I’ve reported the lack of .local to the public suffix list. .local is defined by RFC 6762, so is a valid public TLD.

Perhaps you might star the issue over there?

publicsuffix/list#1466

Though I do not see this on the public suffix list used, and in the linked issue the maintainers closed this as “:x: wontfix


This perhaps could be explained in this comment further down in the post.

As a temporary workaround, you can change the match detection options from the default ‘Base domain’ to ‘Host’. This is working for my local .lan addresses now, but will likely break auto-fill on sites that share the same credentials across multiple sub-domains or ports.

Referencing my logins for work they either have URIs set for the pure https:Hostname:port or https:Hostname.domain.local:port with match detection also set to Host.
I believe this was due to some machines running multiple services on the same Hostname but with different ports i.e https:Machine1.domain.local:8080 & https:Machine1.domain.local:8443, etc.


@justarandomsysadmin Perhaps you can test your http://gitlab.whateverinternal.lan your login is set to and test to see if the Host match detection will work for you?

While I don’t currently have any HA setup, I do have a few internal services running behind a reverse proxy and some others that are not. As mentioned I use the Host detection for internal services as the standard Base domain function would match all different logins for separate services from sub-domains, as expected from the documentation.
I.e machine1.corp.domain.tld & machine1.corp.domain.tld
The Host option allows for Bitwarden to separate logins for the separate internal services.


One last thing I can possibly think of would be to check your URI matching, if it is set to your default Starts with as you say. Possibly check for any discrepancies in the URI such as a trailing /, according to https://bitwarden.com/help/uri-match-detection/#starts-with

For example, if the URI https://sub.domain.com/path/ uses starts with match detection:

URL Auto-fill?
https://sub.domain.com/path (absent trailing slash) :x:
1 Like

Thank you for the insightful answer.

I have tried to set the URL-matching to the host with the respective port, but it hasen’t worked yet.

The only thing that has worked out is to set the IP of the application and then actually calling the website like http://<ip-address> but this is no solution for our end users (that very limited IT knowledge) and doesen’t work with most applications that have a proper ROOT-URL set:

I know that this is basically a niche issue that not many people are experiencing, but it’s kind of a bummer especially since we have chosen to get the enterprise plan and host multiple internal sites for which the users basically can’t use one of the main funcitons of bitwarden properly.

I too am experiencing this issue on specific internal servers in my workplace with the browser extension in Chrome and Edge in a Windows 10 environment.

The issue though started about a month ago.

I have several internal servers in multiple DEV/QA/PROD that I have multiple URLs assigned the same LDAP username and password which I have to change every 60 days. About a month ago, it stopped working and I have to get to resolve.

I am and have been using Default Detection with autofill for over a year.

Please advise

@OhioN8v are the affected sites running behind a reverse proxy?

@cksapp You’ve mentioned that you do have a few internal services running behind a reverse proxy, but not if these specific entries are recognized by bitwarden. Can you test this and try to reproduce this specific scenario for us?

I have been in contact with enterprise support and sadly haven’t got any response regarding this, not even an acknowledgement that this is in fact an issue or it being recognized as such.