Scaling web servers is a different task from scaling web socket servers (e.g. because HTTP is inherently stateless while web sockets are inherently stateful and many other reasons). Thus my recommendation is to always host your web socket service on a different domain to enable hosting it on a different infrastructure.
While native web sockets make cross domain access easy this is no longer true when you start using all the work arounds (e.g. by using socket.io) like XHR long-polling, multi-part XHR and html-files.
It is important to note that even for clients that do support web sockets often you cannot use them because popular web proxies such as squid do not support web sockets.
Access your web socket service through a proxy iframe. This invisible iframe is hosted on the domain of your web socket server and is embedded in your main page. Then access the iframe though the use of document.domain or postMessage. A similar technique (albeit not actually for accessing web sockets is being implemented by #newtwitter. See the source and look for an iframe to api.twitter.com)