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

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.

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

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