If /socket keeps using an old address after a DNS change, inspect its actual proxy_pass form. Having a hostname is different from enabling runtime resolution. A resolver directive alone does not automatically update every literal upstream.
Read the version and configuration form together
The upstream resolve reference describes shared-memory zone and resolver requirements and notes that this feature was commercially restricted before 1.27.3. nginx -v on this host reports 1.24.0, so a current upstream example cannot be copied without checking compatibility.
A variable-based proxy_pass is another option, but read both resolution and URI behavior in the proxy_pass reference. Use a trusted resolver that can resolve the intended internal names. Do not turn the upstream into an unrestricted request-supplied destination.
A DNS fix can also change the forwarded path
location /socket/ {
proxy_pass http://backend.example:8080/;
}
# A variable URI has different replacement semantics:
# proxy_pass http://$backend/;This is a documentation-based comparison fragment, not a complete runnable configuration. The trailing slash on the literal participates in location-prefix replacement; assuming the same meaning for a URI containing variables can lose the path. Verify the actual upstream URI for /socket/a and its query string before and after the change. This can explain a new 404 after what appeared to be only a DNS fix.
Record DNS answers, TTL, selected upstream address and new connections together. Do not expect an already-open WebSocket to migrate merely because DNS changed. No DNS rotation or reconnection was executed here, so no propagation time or uninterrupted failover is claimed.