You could model this where the Controller accesses the Proxy to retrieve its data, and then includes that data in the model for the view to display. This would allow you to do certain things, like hide API access keys or other credentials from the client (very important when consuming many third party services). This also allows you to do things like cache values from a proxy at your controller level - or more likely an injected aspect [i.e., yet another proxy] between the controller and the proxy.
There are situations, however, where you'd consider this problem from the client side and in a web application you might logically think of the solution living in the view (insofar as you may logically think about JavaScript). In reality the actual design is that you have client code that lives in the view that breaks down into its own UML model where there's a controller, model, view, etc. You'd do this in situations where caching on the server backend is unimportant, or where sensitive credential information shouldn't ever leave the client's machine.
When you remove JavaScript from the equation and you are considering just a vanilla MVC design I believe its better to have the controller access the proxy.