Why not just broadcasting the message to all the nodes, and then let the nodes chose the messages they want to forward through WebSockets to clients?
If you have a lot of messages (that much that the impact on the network becomes noticeable), using the user ID in the routing key may be the easy way to reduce the traffic between the MQS and the nodes.
Imagine you have a chat application with rooms and users. Using a topic exchange, you may use routing keys such as
chat.room123.user456 when transmitting a message of user 456 posted in room 123. You can consume those messages by having a queue with a binding key
chat.room123.*, which will listen to all messages in a specific room. You may also want to consume the messages posted by a specific user, independently of the room, using the binding key
chat.*.user456. In order to scale it, you may have some servers handling some rooms, and other servers handling some users. For instance, a given server may have WebSockets connections to users 17, 41 and 48, and have the binding keys
The tricky part here might be the handling of the case where the WebSockets connection is dropped, and the client reconnects to a different node. Sticky sessions may solve this issue. Aside that, handling errors and loss of WebSockets connection is not different from any other scenario where messages from a message queue service should be preprocessed and sent to a third party.