From OP's comment:
@A.B Yes I use wg. When I disable wg the unconn socket is gone. Why wg does this?
It appears the system is configured to bring a WireGuard (tunnel) interface whenever the main interface has a link (carrier detect).
WireGuard requires an UDP socket to communicate with the peer. That's true both for the kernel implementation (kernel module wireguard.ko, eg: ip link add wg0 up type wireguard) or the userspace implemetation (eg: wireguard-go wg0 + ip link set wg0 up).
If the WireGuard configuration doesn't specify the local port, it's chosen dynamically at random. That's often the case for a "client" WireGuard interface (even if WireGuard is following a peer-to-peer model): usually the side which doesn't have a stable public address and can't be reached before there's a tunnel.
To confirm the relation between this UDP port and the dynamic WireGuard configuration, just run wg. Even for a completely unconfigured interface it will at least display something like:
interface: wg0 listening port: 36387 which will be the port used when the interface is UP (kernel implementation), or in all cases (as currently seen with wireguard-go).
When it's handled by the kernel, the port is listening only when the interface is up. But if the port changes, that means each time the interface was deleted and recreated (else the same port would reappear). there'sThere's no process information associated to the socket because it's handled in kernel.
Notes about UNCONN which means socket in unconnected state.
Unconnected doesn't mean there's an error or a timeout. It's one of the two ways to use UDP sockets in communication. It allows to use a single socket to communicate with multiple peers in an efficient way.
Both WireGuard implementations use an UDP socket in unconnected mode: at least for userspace that means it doesn't use connect(2) on this socket and communicates using sendmsg(2) rather than send(2)/write(2) (and likewise recvmsg(2) etc. in the other direction).
