Brave seems to be replacing text I type into the address bar

Description of the issue:
When I type the specific local URL localhost:8088 directly in the address bar Brave insists on trying to load localhost:8088/cgi-bin/luci which results in a 404. This is an address I’ve visited in the past, but not what I’m trying to visit now. I don’t seem to be able to persuade Brave to not do this.

Note that this doesn’t seem to be an autosuggest issue. There is nothing else in the address bar when I hit the enter key.

This also isn’t a broken redirect from the target page. When I run curl localhost:8088 from a command line I get the following:

<!doctype html>
<html>
<head>
<title></title>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
<meta http-equiv="X-UA-Compatible" content="IE=edge" >
<meta http-equiv="Pragma" content="no-cache" />
<meta http-equiv="Cache-Control" content="no-cache, must-revalidate" />
<meta http-equiv="Expires" content="0" />
</head>
<body>
</body>
<script>
window.location.href = "./doc/page/login.asp?_" + (new Date()).getTime();
</script>
</html> 

Successfully loading that should cause Brave to redirect to the server’s login page, not cgi-bin/luci.

How can this issue be reproduced?
I don’t think I can give any specific steps for this.

Expected result:
Brave should just load the page I requested, not a page I’ve visited in the past.

Brave Version( check About Brave):
v1.79.123 (Jun 11, 2025)

Additional Information:
For further context, I’m using ssh tunnelling to configure various servers on a remote network. For each server I create a tunnel from local port 8088 to the remote server’s UI. So localhost:8088 took me to the router’s config page (cgi-bin/luci) at one point, but now is configured to take me to the UI of a different server. I could simply use a different port number for the tunnel, and that’s the workaround I’m about to use, but surely the behaviour I’m seeing is not right?

@dev0173

https://community.brave.com/search?q=localhost%20macos%20order%3Alatest

https://community.brave.com/search?q=local%20address%20bar%20macos%20order%3Alatest

Thanks for that. I’ve searched around a bit and found a couple more reports of similar/same behaviour.

Apologies for creating a duplicate topic, but neither of these contain a confirmed fix/workaround.

@dev0173

10 to 20 years ago, I was doing a lot of SSH Port Forwarding. In order to secure a level of certainty / reliability when making such connections, I always MANUALLY SET in advance at both ends of the tunnel (Party A < – > Party B):

  • DNS server numbers
  • IP addresses
  • Subnet Mask numbers
  • Gateway IP address numbers

I usually made the SSH connections by using the command line (Windows OS CMD Prompt; MacOS Terminal.app). I never used ports 80, 8080, 8088, 443, 8443 (nor other HTTP/HTTPS ports) for the Port Forwarding at the initiating end (Party A device) of the tunnel, but I used the router’s settings at the other end of the tunnel, to forward SSH traffic to the Listening Port of the Party B device. (I sometimes used SSH software - an app named VNC, and RealVNC - on the Mac. There was a particular D-Link DFL-200 model of combo-cable-modem-router that had SSH-VPN tools with excellent documentation.)

Now days, from my older perspective, there is a blizzard of automatic, fill-in-the-blanks, OS magic that is supposed to make things convenient / easier, but also easily gets in the way (and gets stuck).

The procedure for viewing the Windows OS DNS Cache, is relatively more simple than viewing the MacOS DNS Cache (where, last I checked, I had to make a detour thru the Mac’s Console.app - I already forget the gimmick).

Anyway, my “belief” is, that MANUAL setups afford more stable data in DNS Cache observing. And I am not reluctant to flush cache, flush history, flush DNS Cache.

I would never use an Internet browser window for establishing an SSH connection between computing devices (PC < – > Mac); but of course, I would use an Internet browser window of whatever is a router’s embedded website, for that work ← IF allowed for establishing a router to router SSH or other VPN tunnel.

I can safely say that SSH port forwarding isn’t part of the problem here, because I’ve just started a local instance of Tomcat on port 8088 and Brave can’t access that either on localhost:8088. The behaviour is the same … Brave is insisting that I really wanted localhost:8088/cgi-bin/luci and I get HTTP 404 as a result.