To verify that you're talking to the remote server you want directly, two points are required:

   * You need to check you trust the server certificate (typically done via [RFC 3280][1]/[RFC 5280][2]).
   * You need to check that the certificate was issued for the host name you're trying to reach ([RFC 2818 Section 3.1][3] and [RFC 6125][4]).

What constitutes that remote server is up to the service provider. You're confusing multiple kinds of proxy servers here.

   * There are normal HTTP proxy servers that can be used for HTTPS connections. This is done using the HTTP `CONNECT` verb and the entire SSL/TLS traffic between the browser and the target server is merely relayed by the proxy server. As far as the SSL/TLS connection is concerned, this is roughly equivalent to IP routing: the proxy won't see anything.

   * There are HTTP reverse proxy servers. This is what's discussed in [the question you link to][5]. However the request is then handled internally is up to the service provider.

     In the same way as [for database connections][6], it may be useful for the service provider to protect its internal HTTP traffic using SSL/TLS, if the requests are served by HTTP worker nodes. In this case, the head node of the load-balancer/reverse proxy will be the client to those internal web servers.

     As far as you're concerned, the "true site" is the head node/reverse proxy. `https://www.google.com/` certainly has more than just one box to handle the requests it gets. As far as you're concerned, the entire cluster behind it is the (big) machine.

   * MITM proxy servers. Some HTTP proxy servers will be able to look into the HTTP traffic (for example [Squid + SSL Bump][7]). To do so, they will re-generate a certificate using their own Certification Authority on the fly. Such certificates will fail validation in your browser (step 1 above), unless your machine has explicitly been configured to trust this local CA.


  [1]: http://tools.ietf.org/html/rfc3280
  [2]: http://tools.ietf.org/html/rfc5280
  [3]: http://tools.ietf.org/html/rfc2818#section-3.1
  [4]: http://tools.ietf.org/html/rfc6125
  [5]: https://security.stackexchange.com/questions/14597/
  [6]: https://security.stackexchange.com/q/14334/2435
  [7]: http://wiki.squid-cache.org/Features/SslBump