Something’s off here. The gateway does not 404 when it cannot find content on IPFS, because it tries to find it and eventually times out with a 5xx I think.
In any case, you should check that the content was actually successfully pinned in both places (ipfs-cluster-ctl status), and that the request on the gateway is actually for content that was pinned on that local node.
404 is returned when the link is invalid, not when it is not accessible.
For example you tried to access the file Qmfoo/abc but the Qmfoo directory doesn’t have a file named Qmfoo inside it.
In other words, you see 404 when IPFS “proved” that this path is and will always be invalid.
This has been all released out of CD/CI for months… with content updates weekly.
nothing is manual. we pin to the cluster from gitlab pipelines and so we update the DNS __dnslink entries
the content setup is correct.
something broke the content delivery after the connectivity is down.
something has upset the IPFS or the haproxy in front.
actually the haproxy in front is serving just non-IPFS sites just fine…
The you should be able to curl the local ipfs gateway at localhost:8080/ directly for the content and see if it returns it, or what kind of error it gives.