VSTS Octopus Push through a proxy


We have an on-prem VSTS Build Agent and an on-prem Octopus Server. The Octopus service connection in VSTS is set up using http and an IP address (e.g. - the actual IP is different). There is a proxy for outbound internet traffic.

I’ve set up the VSTS agent using the new settings to set the HTTP proxy at the agent level, rather than the old method of setting proxy environment variables. My agent root folder has a .proxy file and a .proxybypass file which I’ve created to skip the proxy for the Octopus connection.

The .proxybypass file contains one entry in the recommended regex format:

The Octopus Push V3 build step in VSTS is failing with a 407 tunneling error. The following is an extract from the build job:

2018-08-22T04:37:26.1521390Z ##[debug]check path : F:\Agent_01_work_tasks\OctopusPush_d05ad9a2-5d9e-4a1c-a887-14034334d6f2\3.0.168\node_modules\vsts-task-tool-lib\lib.json
2018-08-22T04:37:26.1523869Z ##[debug]set resource file to: F:\Agent_01_work_tasks\OctopusPush_d05ad9a2-5d9e-4a1c-a887-14034334d6f2\3.0.168\node_modules\vsts-task-tool-lib\lib.json
2018-08-22T04:37:26.1524476Z ##[debug]system.culture=en-US
2018-08-22T04:37:26.7273976Z ##[debug]OctoConnectedServiceName=28fb11db-c16d-400e-b610-a37e826d11ff
2018-08-22T04:37:26.7293033Z 28fb11db-c16d-400e-b610-a37e826d11ff exists true
2018-08-22T04:37:26.7293483Z ##[debug]28fb11db-c16d-400e-b610-a37e826d11ff exists true
018-08-22T04:37:26.7348961Z ##[debug]28fb11db-c16d-400e-b610-a37e826d11ff=
2018-08-22T04:37:26.7352417Z ##[debug]Package=F:\Agent_01_work\37\a\Automation.Packages*.nupkg
2018-08-22T04:37:26.7370151Z ##[debug]Replace=False
2018-08-22T04:37:26.7370702Z ##[debug]AdditionalArguments=null
2018-08-22T04:37:26.7384844Z ##[debug]which ‘Octo’
2018-08-22T04:37:26.7693472Z ##[debug]not found
2018-08-22T04:37:26.9116209Z ##[error]Error: tunneling socket could not be established, statusCode=407
2018-08-22T04:37:26.9193235Z ##[debug]Processed: ##vso[task.issue type=error;]Error: tunneling socket could not be established, statusCode=407
2018-08-22T04:37:26.9193821Z ##[debug]task result: Failed
2018-08-22T04:37:26.9194302Z ##[error]Failed to push package. tunneling socket could not be established, statusCode=407
2018-08-22T04:37:26.9194788Z ##[debug]Processed: ##vso[task.issue type=error;]Failed to push package. tunneling socket could not be established, statusCode=407
2018-08-22T04:37:26.9209117Z ##[debug]Processed: ##vso[task.complete result=Failed;]Failed to push package. tunneling socket could not be established, statusCode=407

The Octopus Push V2 version does work, probably because it’s using octo.exe and bypassing the http proxy by default.

Any assistance would be appreciated!


Hi Larry,

So, as I understand it, the VSTS Agent is trying to use a proxy and getting 407 Proxy Authentication Required status, even though you want it to bypass, as per this document?

My immediate thought is that it’s not matching the pattern in the .proxybypass file, is VSTS maybe trying to use a hostname rather than the IP address? That’s my first thought. Have you tried other patterns in the .proxybypass file?

Hi Jason,

Yes the page you sent through is how I’ve configured the proxy. The rest of the build steps (e.g. downloading from source control and actually triggering the build itself) are working normally through the proxy. We have other build jobs also functioning normally. So the proxy config in the agent seems correct.

I have tried a number of combinations in the .proxybypassfile and I’ve confirmed that the service endpoint in VSTS is actually an IP address and not a host name. It’s an IP address and I used a two different online JS RegEx matching websites to confirm that my regex was correct.

Just wondering - are there possibly any other supporting jobs within nodejs that may be trying to run in the to prepare the task for execution (e.g. NPM or something like that)?

Hi Larry,

I’ve done a bit more reading. I suspect the .proxybypass method is only going to affect the bahaviour of the VSTS agent itself, not the behaviour of external executables like octo.

A few previous customers have had similar issues, and one that stands out is this post


Which was solved using the “internet options” dialog. That setting can apparently be automated by setting the value of the following registry key to include “”

HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings\ProxyOverride

Are you able to give that a try and report back if it works?



Hi @Jason_Brown thanks for the info. The service account that is used to run the agent is different to the login account when connecting via RDP to our build server. The proxy settings for the service account are also different. Modifying the internet settings would need to be performed through the registry.

The advice I would give our clients (which I’m going to follow myself) is that modifying registry settings should be a last resort if there are other options available. We generally try to limit the amount of “snowflake” custom configuration we need to do on our cloud servers (including the build server). In this case the V2 version of the task still works and if that is retired, the preference would be to execute a custom PowerShell script that calls octo.exe directly or nuget push (or even uses the API if necessary).

Since our build server is mission critical at the moment, I’m going to avoid doing any direct modifications to the registry that could impact other build activities and bow out of this one until V2 of the “Push” is retired!

Thanks again for the assistance!