Problem using Golang proxy repository from a non-internet-connected client machine/container

post by thomas.jordan on Dec 18, 2025

Hi,

I’ve created a Golang Proxy repository in Nexus. The configuration is as follows (I’ve hidden the path to our repo and the last two HTTP check boxes are left unchecked):

In a Docker container run up from the official Golang docker image, on a normal, internet-connected machine, after setting $GOPROXY environment variable in the container to point to the Nexus repo, everything appears to work as hoped. Specifically if I follow the steps of the Tutorial: Get started with Go - The Go Programming Language, go mod tidy creates a go.sum file and populates the go.mod as follows:

root@c7b5c1bb00e1:~/hello# more go.mod
module example/hello

go 1.25.5

require rsc.io/quote v1.5.2

require (
        golang.org/x/text v0.0.0-20170915032832-14c0d48ead0c // indirect
        rsc.io/sampler v1.3.0 // indirect
)
root@c7b5c1bb00e1:~/hello#

the dependencies appear in the repository and the example code builds and runs fine.

The populated repository then looks as follows:

I’ve also tried building a couple of other, slightly bigger examples with more dependencies and everything seems to work fine.

However, our main use case for Nexus is as a proxy accessible from a non-internet connected network and that’s where the problem lies. I should say we already use Nexus for proxying apt, yum, PyPI and DockerHub repos which all work fine from the non-interconnected network, but I have now been requested to add GoLang proxy.

The problem I see is evident in the following output. This is produced when I delete all the folders from the Nexus proxy repository and start from scratch trying to run the aforementioned Golang tutorial example, on a GoLang Docker container running on the non-internet connected network, with $GOPROXY again set to point to our Nexus proxy.

root@ddb1faf21e24:~# mkdir hello
root@ddb1faf21e24:~# cd hello/
root@ddb1faf21e24:~/hello# go mod init example/hello
go: creating new go.mod: module example/hello
<Creation of hello.go here ommitted to save space>
root@ddb1faf21e24:~/hello# ls
go.mod	hello.go
root@ddb1faf21e24:~/hello# more go.mod
module example/hello

go 1.25.5
root@ddb1faf21e24:~/hello# go mod tidy
go: finding module for package rsc.io/quote
go: downloading rsc.io/quote v1.5.2
go: example/hello imports
    rsc.io/quote: rsc.io/quote@v1.5.2: verifying module: rsc.io/quote@v1.5.2: Get "https://sum.golang.org/lookup/rsc.io/quote@v1.5.2": dial tcp 142.250.140.141:443: connect: connection refused
root@ddb1faf21e24:~/hello# go run .
hello.go:4:8: no required module provides package rsc.io/quote; to add it:
    go get rsc.io/quote
root@ddb1faf21e24:~/hello# go get rsc.io/quote
go: downloading rsc.io/quote v1.5.2
go: rsc.io/quote@v1.5.2: verifying module: rsc.io/quote@v1.5.2: Get "https://sum.golang.org/lookup/rsc.io/quote@v1.5.2": dial tcp 142.250.140.141:443: connect: connection refused
root@ddb1faf21e24:~/hello# more go.mod
module example/hello

go 1.25.5
root@ddb1faf21e24:~/hello# go run .
hello.go:4:8: no required module provides package rsc.io/quote; to add it:
    go get rsc.io/quote
root@ddb1faf21e24:~/hello#

You can see that the go mod tidy results in a connection refused. However, the repository does get populated at this point, though no requirements are added to the go.mod file and no go.sum is created.

If I copy across the go.mod and go.sum that were successfully modified/created by go mod tidy on the other, internet-connected network, where everything built and run fine, to the non-internet-connected network, then run

go run .

on the non-internet connected network, it builds and runs the application fine, just as on the internet-connected network.

So it seems like things ‘half-work’, in that I can pre-populate the proxy repository from the internet-connected network and then pull the packages from the proxy repository down to the non-interconnected network in order to build. That is not really a viable workflow, though and we don’t have to do anything like that for the other proxy repositories we have set up in Nexus.

I’m not familiar with Go repositories/modules/packages etc., Go is not my primary programming language, but I was hoping by creating the repo in Nexus and setting $GOPROXY to point to it on my client VM/container, that would work and all dependencies would come down through the proxy.

Can anyone tell me what I might be doing wrong? Any help would be much appreciated.

post by mpiggott on Dec 18, 2025

You might need to set the Max Metadata Age to -1 which would disable going to the remote for cached metadata.

post by thomas.jordan on Dec 19, 2025

I’ve now tried that, Matthew, but unfortunately it appears to have made no difference - I see exactly the same.

post by thomas.jordan on Jan 8

Hi,

I’m still stuck on this, I’d appreciate any further suggestions.