The short answer is that it depends on how complex a router or firewall you have connected to the Internet. Home grade equipment will likely not be able to do what you want.
Probably the best thing to to is to explain why...
Let's consider the pieces in the jigsaw... Initially we will think about non-ssl websites (ie HTTP rather than HTTPS)
Firstly consider DNS. When someone visits one of your sites, their system will retrieve the internet facing IP address of that site from internet facing DNS. The conversation between their browser and your published site will be to that IP address.
It is possible to have multiple sites hosted on one public IP address, but the process above will be the initial step, and communications will be to the IP address determined by DNS. The domain name of the site does not come into the routing of the traffic once DNS has proclaimed which IP address to talk to.
The routers that make up the Internet and consumer grade DSL routers will only make decisions based on the destination IP address and port of the traffic (OK I have made big simplifications in that assertion, but for our purposes they are justified).
Your DSL router (or simple corporate router or firewall) will receive a TCP connection to port 80 of its external IP and use port forwarding to forklift that traffic directly to a single internal server.
OK so I've just said that multiple sites can share an IP address, but then seemed to contradict myself by saying that the traffic will be routed to the same server as it has the same destination IP address and port. So what is different between the requests that allows the differentiation based on requested site to be made?
The HTTP requests them-self contain the name of the site being requested (as part of the HTTP application protocol), however as the requested site name is buried in the application level chatter, normal routers cannot take decisions based on it. In fact (although it is VERY likely to be) the requested host information may not even be in the first physical IP packet sent across the established TCP connection.
The actual request passed across the TCP connection (which you will recall is made to the IP address retrieved for the site) may be as simple as...
GET / HTTP/1.1
(followed by a blank line)
This says GET the default page for the website site using the HTTP 1.1 protocol. Oh... and by the way, the site we are interested in is "www.bleepingcomputer.com".
In order to take decisions based on the name of the requested site, the device or server making that decision needs to be thinking at the application level - most routers do not do that.
So what can do that?....
Well the web server itself will be able to. If you host multiple sites on one server then you will need to configure each site with a unique combination of IP address, port, and host-header. From that information the server knows which site to reply as.
You seem to say that you have multiple servers, hosting separate collections of sites, but sharing the same internet facing IP address. Well in that case, the servers themselves can't make the decision by themselves, as we need to decide which server to route the traffic towards before the servers ever see the request.
As others have said above, a proxy device inside your network between your router and the servers could listen to all requests, analyse them at the application level, and pass the (now sorted) requests to the correct destination web-server.
Mid-high level corporate firewalls can also include this kind of technology in the firewall itself (and can even go further, sending request for let's say the '/news' part of a site to server "A" and the '/sport' part of the same site to server "B"). This would be the more usual way of handling this situation.
I mentioned at the top of this post that there is something different about SSL sites (HTTPS).
In the case of SSL sites, the traffic is theoretically encrypted all of the way between the browser and web server. However the same trick with the "host" header goes on within the conversation between browser and server. The gotcha, there is that since the host header is within encrypted traffic, it cannot be used for routing decisions at all. As always, there is a need to do this, and the workaround is to allow your (complex) firewall access to the servers SSL certificate, to that it can decrypt the traffic, examine the host header and route it through its server publishing logic. This is of limited value however as part of the SSL protection is to prove that you are talking to he correct server for your requests site - so the certificate itself is specific to the requested server name.
(edited to add extra text to the SSL paragraph)
Edited by x64, 11 September 2014 - 05:50 AM.