Configuring Launcher with proxy requiring authentication

I get the following error(s) in the logs on starting Launcher:

[error] FetchError: request to failed, reason: getaddrinfo ENOTFOUND

The reason, I’m sure, is because of my company’s proxy that requires a username and password. The problem is the same on both Windows and Ubuntu. I can access that file through a web browser, since the browser respects the configured https_proxy environment variable. If I change networks to one without a proxy, the launcher goes ahead as normal. Unfortunately I can’t leave it connected to the unsecured network, so even after accepting the EULA etc the launcher is fairly useless.

I have tried using the option on both Windows and Ubuntu, without any luck. The wiki says to leave off the http:// string. It seems like the option might not respect the username:password part? Is there a workaround?

Hello @jason.anderson! We are looking into the issue. Thanks for letting us know!

Working solution: I set proxy ONLY with --proxy-server option, disabled any proxy settings in Ubuntu Desktop. Ran the launcher to get past initial accepting EULA. Then terminated app and enabled Ubuntu Desktop proxy, and left --proxy-server option enabled, was able to proceed normally.

So it looks like the launcher might be getting the proxy configuration from both the Ubuntu Desktop network manager and the command line? If I disable the network manager proxy (ensuring http_proxy is blank in terminal) and start the launcher with --proxy-server set, it works. If I put anything in the network manager proxy settings, it will not work, with or without the --proxy-server option.

For the devs, my best guess is that since Ubuntu Desktop’s network manager requires http:// in front of the address, and --proxy-server requires only host and port, there is some kind of mismatch. Please let me know if I can test any other configurations to help solve the issue.

1 Like

Do you know how to set “–proxy-server” on Windows? Thanks in advance.

1 Like

Has there been any update on this? It seems to me like the error is in the string parsing of the --proxy-server parameter. If you launch like this:


the launcher logs will look like this:

13:48:06.351 › Using proxy server SERVER:PORT for the main process.

and of course fail to authenticate if the proxy server requires authentication. However, if you launch like this:


the launcher logs will look like this:

13:48:06.351 › Using proxy server USER:PASS@SERVER for the main process.

See how it simply used the first two strings surrounding the “:” for the server and port? The argument parser needs to split the string on the LAST “:” character (and only on the last “:” character) for the simplest fix, or better yet, properly handle the optional USER:PASS authentication.

1 Like

Hello @navajerry98! Can you attach a copy of your logs found here: C:\Users\<USERNAME>\.nvidia-omniverse\logs\launcher It might have some clues that will help us troubleshoot the issue.

It turned out for us that the easiest solution was to set up CNTLM in Ubuntu to handle our company proxy authentication, and then pass the local proxy to the launcher using --proxy-server= This works for everything but Isaac Sim, which I’ll make a new post about.

I confirm @navajerry98 's remark.
It appears that the port gets lost when including the username and password in this form --proxy-server=username:password@server:port
So when I put that I get : Using proxy server for the main process.
I have attached an extract of my launcher log with that part where I changed some strings for privacy purposes.
launcher_extract.log (5.0 KB)

And when I only put the server and port info without user:password@, I get : Using proxy server for the main process.
And no errors except aPROXY_AUTH_REQUIRED notification when when trying to connect to which is normal I think.

let me know if there is a workaround I can do for now, this issue prevents many of my colleagues from testing omniverse.

Unfortunately it looks like the launcher doesn’t pass the proxy settings to the applications it launches (like Nucleus and Isaac Sim), so even though we handled proxy authentication with CNTLM we’re still stuck when Isaac Sim needs to access resources or when Nucleus mounts the AWS NVIDIA share. We’re looking into using a transparent proxy on our workstations to avoid configuring it in applications altogether.

IMO it would be nice if all of the Omniverse applications would simply respect the http(s)_proxy and no_proxy environment variables - that’s what they’re for.

1 Like