Don't use the connection: close header in your redirect unless you are sure the connection won't be needed. That's because connections can often be reused especially in HTTP/2 which uses the same TCP connection for every hostname with the same IP address and port number.
For example if you are redirecting from https://example.com to https://www.example.com in HTTP/1, these would each require two different connections. But assuming they share the same server IP address, HTTP/2 will automatically reuse the same connection in the second request which saves overhead and time. (HTTP/2 also supports server push which means you could further speed things up by pushing the new URL along with the redirect.)
HTTP/1.1 will also automatically reuse the connection if both the hostname and the port number are the same, like when redirecting from http://example.com to http://example.com/home/
I will also add that if you can just return the resource rather than returning a redirect that will be faster and you should just consider doing that along with a link header telling search engines where the canonical URL is. That especially works well when the only thing different is the path, because then with a little bit of JavaScript you can also change the location bar to show the canonical URL with History.replaceState(). The effect is the same as a redirect without the overhead of a redirect.
I've literally never added connection: close to a redirect, but I could see doing it when you're sure the connection isn't needed anymore like when redirecting from http to https which will always require a new TCP connection.