Client to sync gateway connection with proxy problems


I have 2 environments:

Fully working Environment

  • 3 Windows machines in one network
  • machine 1 has .net core 2.2 client
  • machine 2 has sync gateway 2.5
  • machine 3 has enterprise server with latest version 6.x
  • Client connects using ws://sync-gateway-host:ip/db successfully! client can push and pull in both directions. Everything is good!

None working Environment

  • Moved server and gateway to openshift in another network.
  • From the client machine, the Sync gateway is reachable via Admin API in the browser!
  • Client is unable to connect to the sync gateway using ws://sync-gateway-hos-in-openshiftt:ip/db!

the client fails with the error message: Invalid URI: The hostname could not be parsed. this is obviously caused by a call to WinHttpGetProxyForUrl, the client tries to create a WebProxy class using a null url.

How can I make my client in network 1 reach the sync gateway in network 2?


this is obviously caused by a call to WinHttpGetProxyForUrl

What is the proxy configuration on the client network? (I.e. not any reverse proxy the server is behind, but a regular client proxy.)

I’m not familiar with Windows networking; do you think this is a bug in CBL’s proxy handling? (Paging our .NET experts @Sandy_Chuang and @borrrden…)

From the client machine, the Sync gateway is reachable via Admin API in the browser!

In case you’re not aware, that’s a major security problem for a production environment, since the admin API gives “superuser” access to Sync Gateway.

I assume you are using .Net Core 2.2 CBL 2.5?
The way to use client side proxy which currently CBL supports is to setup proxy server where CBL connects to, then the CBL will detect the system wide proxy and redirect connection base on the proxy server config, refer to Windows 7 if you are running CBL .NetCore ( then connect to Sync Gateway. If you don’t intent to use system proxy, please clear all your proxy setting on your machine.

The other place where this could be going wrong is in the PAC script from your network. I think you also posted this on stack overflow, but the line you posted is during a potential PAC lookup and execution.

Hi Jens,

The client machine always uses a configuration script PAC file.
Thanks for the notice, I am fully aware not to expose the admin port api in production.

Hi borrrden,

Does this mean that CBL 2.5 is unable to get through a PAC configuration script?

I don’t know what it means, because the call is indicating success or it would not reach that line. I wonder if your PAC script is mistakenly returning null?