Cannot administer embedded systems due to blocked ports

I am a system administrator who administers many embedded systems. Some of these systems intentionally use unusual TCP ports for their administrative interfaces. We’d like to use the Brave browser in our work, but it is blocking access to those ports. Adding the --explicitly-allowed-ports=[list] command line switch to the Windows shortcut that launches the browser used to circumvent this problem, but has stopped working. We are professional system administrators and do not need “training wheels.” Do we have to give up on your browser for professional work?

To reproduce, try to access any device with a Web interface on a port other than 80, 443, or a few other common ones. (Note that there is no public documentation of exactly which ones will be blocked and which ones will be allowed.) You’ll get an error page with the error ERR_UNSAFE_PORT. We have found no way to circumvent this error with command line switches. We are currently trying and failing to find a workaround on your release 1.40.109.


If you have a Brave Browser installation that you might sacrifice, by going to:

  • brave://settings/reset

and then reset . . .

OR test a new Profile.

You probably have already seen the following:

but that may interest passersby.

Two Brave URL’s to look at:

  • brave://management/
  • brave://policy/

Unfortunately, none of this seems to make a difference. The registry setting mentioned in Google’s documentation doesn’t exist on my system, and the brave://policy page lets me see that there are no explicitly allowed network ports but does not allow me to set any. I am wondering if perhaps Google (in keeping with its corporate philosophy of dictating to users what they can and can’t do) disabled this in the code and the maintainers of Brave simply brought it in without realizing that it made their browser useless to administer many embedded systems.


If that command line switch (--explicitly-allowed-ports=[list]) is going to work, it would at least have to [wouldn’t it?] work for Microsoft Edge.

Also, odd that, for example: connection does not work for Brave Browser. (After, for example, you had to use Firefox to gain access and set that port.)

BTW, did you try to gain access via a mobile device, using Brave Browser set to ‘Private Browsing Only’?

Microsoft Edge:

Maybe try . . .

Go to: brave://flags/

Search for and Disable: Block insecure private network requests

If that does not fix your issue, then set that back to Default (as it was, before an adjustment).

In a Brave Browser - New Window, go to: brave://settings/shields

  • Disable: Auto-redirect AMP pages (AMP - Google’s Accelerated Mobile Page)
  • (Alternate setting for older Brave Browser versions, try: Disable Enable De-AMP at brave://flags)
  • Disable: Upgrade connections to HTTPS (HTTPS EVERYWHERE toggle switch)

Next, in a Brave Browser > New Window, go to: brave://settings/security

  • Disable: Always use secure connections (‘HTTPS ONLY’ toggle switch.)
  • Disable: Use secure DNS
  • Safe Browsing test/try No protection

Next, go to: brave://settings/content/javascript

Scroll down that javascript settings page to Allowed to use javascript

Click the Add button

Enter:[port] as the site . . . but Do Not Enable

UPDATED: Enter: as the site . . . but Do Not Enable

  • Current Private session only

Click the Add button

Next, go to: brave://settings/content

Scroll down to Content

  • Pop-ups and redirects: Don't allow sites to send pop-ups or use redirects

Service Name and Transport Protocol Port Number Registry

Verify Command Line start. Double-checking: brave://version

If an error is made in the command line string(s) used (textual error when writing, or misplacement of the switches), then a double-entry of one or more switches may show.

Good idea to maintain a recent screenshot of the Command Line entry that exists before any customization. Brave Browser for Mac example, with 3 brave://flags ‘flag-switches’ Enabled:


1 Like

Hey @BrettGlass. I’m not even going to pretend I have a clue in regards to the things you’re talking about. Therefore I don’t have any advice to offer right now. The reason I am responding though is to let you know that with it being the weekend, you’re likely not to have any official response from Brave for a few days. This is because they often have weekends and holidays off. With this being Independce Day weekend, I’m wanting to assume they won’t fully return to the office until Tuesday (July 5).

That said, we do sometimes have @fanboynz who tends to pop in every once in a while. To my knowledge, he is usually more focused on things like Shields. I’ve tagged him though in case this is something he may be able to help on and notices. As to @Mattches or others, they may pop in but don’t be shocked if there isn’t a delay because of holiday weekend. (at least tagged so he’ll see it when back to work)

OF course, you have 289wk, @Chocoholic, and maybe @CerealLover who often know a lot. Looks like 289wk at least is offering some suggestions. Maybe y’all can get it figured out. Fingers crossed on that.

Anyway, just wanted to drop these notes so you know what to expect. Often can get people who expect immediate responses. So if I know might be a delay, I try to drop in to advise.

Interestingly enough, it looks like Firefox does something similar, although I don’t know whether the ports list is exactly the same.

Can you tell us one of the port #s you’re trying to get it to work with?

I don’t see why it would follow that the same command line option would work for an entirely different product. And we’re using Windows laptops, not mobile browsers.

When you attempt to override the blocking in FireFox, it works. It doesn’t work in Brave.

We’re unable to override the blocking for low ports (e.g. 1-20) or for some higher ones (e.g. 6000).

Because latest Edge is also Chromium-based, and so shares many parameters.

It is working for me, tested against 6000.

Do you have this enabled by any chance?

If not, what do you have in brave://version?

Sorry, I can’t help you with your problem. I suggest you create an issue report at Brave GitHub and/or Chromium Bugs. Brave community members and support staff can probably provide basic troubleshooting information, however, if you have already tried the things suggested, you are more likely to get a technical response if you create an issue report at Brave GitHub and/or Chromium Bugs.

Probably what you call training wheels information below, but posting anyway. :grin:

Blocked Ports:
I couldn’t find Brave specific documentation, but found info at The Chromium Project (which definitely apply) and chrome (which may or may not apply). Also posted some Brave GitHub issue reports per proxy setups in case it relates, although I couldn’t determine if this information was still valid.

Chromium List of Blocked Ports

// The general list of blocked ports. Will be blocked unless a specific
// protocol overrides it. (Ex: ftp can use ports 20 and 21)

1, // tcpmux
7, // echo
9, // discard
11, // systat
13, // daytime
15, // netstat
17, // qotd
19, // chargen
20, // ftp data
21, // ftp access
22, // ssh
23, // telnet
25, // smtp
37, // time
42, // name
43, // nicname
53, // domain
77, // priv-rjs
79, // finger
87, // ttylink
95, // supdup
101, // hostriame
102, // iso-tsap
103, // gppitnp
104, // acr-nema
109, // pop2
110, // pop3
111, // sunrpc
113, // auth
115, // sftp
117, // uucp-path
119, // nntp
123, // NTP
135, // loc-srv /epmap
139, // netbios
143, // imap2
179, // BGP
389, // ldap
465, // smtp+ssl
512, // print / exec
513, // login
514, // shell
515, // printer
526, // tempo
530, // courier
531, // chat
532, // netnews
540, // uucp
556, // remotefs
563, // nntp+ssl
587, // stmp?
601, // ??
636, // ldap+ssl
993, // ldap+ssl
995, // pop3+ssl
2049, // nfs
3659, // apple-sasl / PasswordServer
4045, // lockd
6000, // X11
6665, // Alternate IRC [Apple addition]
6666, // Alternate IRC [Apple addition]
6667, // Standard IRC [Apple addition]
6668, // Alternate IRC [Apple addition]
6669, // Alternate IRC [Apple addition]
0xFFFF, // Used to block all invalid port numbers (see
// third_party/WebKit/Source/platform/weborigin/KURL.cpp,
// KURL::port())

Chrome List of Additional Blocked Ports

  • 554 = port 554 (can be unblocked until 2021/10/15)
  • 10080 = port 10080 (can be unblocked until 2022/04/01)
  • 6566 = port 6566 (can be unblocked until 2021/10/15)
  • 989 = port 989 (can be unblocked until 2022/02/01)
  • 990 = port 990 (can be unblocked until 2022/02/01)
Brave GitHub Issue Reports Proxy Setups

Manual proxy setup via Proxy settings doesn’t work in Windows OS’s #20379

Use a local socket for tor socks proxy and control channel where available #650

Other documentation:

Chromium Project Documentation for Administrators/Policy Templates

Documentation for Administrators

Policy Templates

Brave Help Center

Group Policy

How Do I Use Command Line Flags in Brave?

Basic Troubleshooting:


Update broke DNS? - #4 by fanboynz

Is problem reproducible in new test profile, Beta, and/or Nightly?

Other Stuff:
Deviations from Chromium (features we disable or remove)

1 Like

Are you sure that the issue is Brave or it is related to the ports?
I used Brave for the all day work and I use Chrome as well for professional stuff where I cannot install brave.

I have never had any port blocked. Only blocked ports are usually due to firewalls, not browsers.

If it is only Brave, could it be something else that Brave is blocking as part of its privacy features?

To some of the recent respondents: the port-blocking is indeed coming from Brave (via Chromium).

But as best I can tell from testing on 2 machines (1 Windows, 1 Linux) the cmdline override still works. So if it isn’t working for the OP, that is ‘unexpected behavior’ and there is likely a localized reason for it.

Looks like this may be the authoritative list:

1 Like

I am an experienced system administrator and know what I’m doing. I can reach the same ports from the same machine via a Telnet client. Brave is blocking them and displaying the error ERR_UNSAFE_PORT. So, it is the browser that is doing the blocking. The command line switch used to work; it has stopped working. This is a bug - again, most likely instituted by Google, which seems to want to put training wheels on everything EXCEPT its own spying. Please help by reporting this problem to the Brave developers.

P.S. - This seems to be confirmed by inspection of the code at

(thank you for the reference above). It appears that while the command line option still exists, in reality the blocking of ports cannot be overridden at all because the set of ports it is “allowable” to unblock is empty. So, the command line option has been broken, at least in the version of the code one can see there.

Embedded systems often use nonstandard or unusual ports and it is necessary to be able to access them. Please fix this.

@BrettGlass , you took note of this correct?

As an experienced system administrator I wonder what your thoughts might be on why it works on 2 of my systems, but not on yours. In my view this would strongly suggest something different in our circumstances and could lead us to solving the problem for you immediately, if we can narrow down what the difference is.

You’d likely also recognize this:

which is from an instance of Brave with the earlier-referenced cmdline option set to allow port 6000.

So it seems fairly clear that the cmdline option can still work, and if it’s not working for you then we can very likely figure out why.

1 Like

Nope. Doesn’t work, even in a freshly configured new install.

OK, I tried about as close as I can get to your example and it still won’t replicate for me. I used a private address, HTTP (not HTTPS), and port 9 and it still tried connecting – provided that I had the CLI set.

So a few things I’m wondering:

  • Has it been tested after a reboot? (Point being, if there’s a process that didn’t unload, it may not be starting up with the new params.)
  • Do you have this enabled by any chance?
  • What do you have in brave://version in the instance that’s misbehaving?

Couple additional thoughts:

  • Is it a corporate-managed device?
  • Anything in brave://policy or brave://management/ ?
  • Are any extensions installed, and if so, is the behavior the same with them all disabled? (Not sure if your latest fresh install could still be picking up an existing profile directory.)
1 Like

Checked for Brave processes and there were none to unload. Tried reboot; no difference. Background apps disabled. Output of brave://version on machine we tested (some of the settings look as if they invade privacy; will have to turn those off) shows more than 4 URLs and so I have had to delete them. But here goes:

Brave 1.40.109 Chromium: 103.0.5060.66 (Official Build) (64-bit)
Revision 20b1569438a85e631d15e83eb355e3e326e5da6f-refs/branch-heads/5060@{#1066}
OS Windows 7 Service Pack 1 (Build 7601.24546)
JavaScript V8
User Agent Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/103.0.5060.66 Safari/537.36
Command Line “C:\Program Files\BraveSoftware\Brave-Browser\Application\brave.exe” --explicitly-allowed-ports=9 --disable-client-side-phishing-detection --disable-domain-reliability --enable-dom-distiller --no-pings --component-updater=url-source= --origin-trial-public-key=bYUKPJoPnCxeNvu72j4EmPuK7tr1PAC7SHh8ld9Mw3E=,fMS4mpO6buLQ/QMd+zJmxzty/VQ6B1EUZqoCU04zoRU= --sync-url= --lso-url=[DELETED] --variations-server-url=[DELETED] --variations-insecure-server-url=[DELETED] --flag-switches-begin --enable-features=PasswordImport --flag-switches-end
Executable Path C:\Program Files\BraveSoftware\Brave-Browser\Application\brave.exe
Profile Path C:\Users\Brett\AppData\Local\BraveSoftware\Brave-Browser\User Data\Default
Active Variations AdRewardsStudy:NextPaymentDay

Thanks for posting that.

I compared that against mine (a working instance) and while there are some differences, nothing is jumping out at me as a ‘smoking gun’ that would clearly relate to this behavior.

Could you respond to the other questions as well – i.e., is it a ‘managed’ platform (e.g., corporate Group Policy, Intune, etc.); is there anything showing in brave://policy or brave://management; and do you have any extensions installed?

Lastly, it appears you’re running this on Windows 7? Do you have a Windows 10 system you can test with and does it behave the same way?


If you have a Windows OS machine that has not had Brave Browser installed . . .

Get an older version of Brave Browser, at:

Install that older version, on the Windows OS machine that has not yet had Brave Browser installed.

Run the older Brave Browser on that computer; try to make the connection to the embedded web admin system.

If successful, Exit / Quit that Brave Browser.

Compare / Contrast the older Local State and Preferences files . . . with those same-named files of the latest Brave Browser version.

Local State file:

  • C:\Users\username\AppData\Local\BraveSoftware\Brave-Browser\User Data\Local State

Preferences file:

  • C:\Users\username\AppData\Local\BraveSoftware\Brave-Browser\User Data\Default\Preferences

To view the Preferences file, go to: brave://prefs-internals/

Copy and paste all that, into a new text file window.

The Local State file, will require a little more work, to produce a layout that can be Compared and Contrasted.

Perhaps one or more differences between the old and the new Brave Browser version settings, will help you diagnose.