You've come to this page because you've asked a question similar to the following:
What IP address should my proxy server be configured to listen on?
This is the Frequently Given Answer to that question.
The considerations, relating to the IP address on which a proxy server should listen, apply equally to proxy DNS servers, proxy HTTP servers, and SMTP Submission servers. They are all request/response services, and the security considerations for them are much the same across all of the protocols. The security considerations for providing such servers apply equally to proxy DNS servers responding to queries, to proxy HTTP servers responding to request messages, and to SMTP Submissoin servers accepting mail submissions. This is because they are fundamental to the nature of a server for a request/response protocol providing service on an IP address.
Proxy servers do not need to be, and shouldn't be, accessible from the outside world. This is because they do work on behalf of their clients. Because one pays (in traffic charges and storage costs, amongst other things) for that work to be done, one should not provide proxy service free of charge to the rest of Internet.
Some people mistakenly think that access controls, implemented within the server softwares themselves, are sufficient for protecting proxy servers. This is not true. Access controls do not prevent proxy servers from doing work on receipt of queries/requests/submissions. They merely reduce the amount of work that is done. Even discarding a query/request/submission involves doing work. Moreover, access controls cannot prevent several forms of attack:
Access controls cannot prevent denial of service attacks such as request/query/submission flooding, or queries/requests that deliberately involve expensive back-end processing. An attacker can impersonate a legitimate client, such as by forging the source address on IP traffic, for one thing. It doesn't matter that the attacker doesn't receive the return traffic (although if the attacker has control over IP routing this is possible). The denial of service is in getting the server to spend processing resources doing work.
Access controls cannot prevent attacks where an attacker attempts to insert false data into a proxy DNS/HTTP server's cache by attempting to impersonate one of the content servers, that the proxy server's back-end would contact, providing a response to a request. (Attackers usually try to ensure that the proxy DNS/HTTP server's back-end is making the relevant request by also impersonating a legitimate client sending the query/request message to the server's front-end.)
The way to prevent the server from doing work, and to prevent denial of service and poison insertion by impersonation attacks, is to stop all unauthorized query/request message traffic from reaching the proxy server in the first place. The proxy server must be configured to listen on an IP address that is, quite simply, not reachable from the rest of Internet, and not reachable from outside of the machine, site, or organization where the clients that it is intended to serve reside.
The address to use depends from what clients the server is intended to provide service to:
If proxy service is only intended to be provided to clients on the same machine as the server, one has the proxy server listen on an address that other machines and the rest of Internet cannot route traffic to from outside of the machine itself. This will usually be an address bound to the machine's "loopback" network interface, such as ::1 or an address in the 127.0.0.0/8 range.
If proxy service is only intended to be provided to clients within the same organization, one has the proxy server listen on an address that the rest of Internet cannot route traffic to over the organization's borders. For examples:
One has the proxy server listen on an address in one of the RFC 1918 non-public IP address ranges, and ensures that all traffic with RFC 1918 non-public IP addresses is stopped at one's borders. Or one has the proxy server listen on an address in a "site local" or "(probably) unique local" IP address range, and ensures that all traffic with "site local" or "(probably) unique local" addresses is stopped at one's borders.
One has the proxy server listen on a real, honest-to-goodness, public IP address, such as 2001:0DB8::1, and ensures that all traffic with that IP address is stopped at one's borders.
One has the proxy server listen on a real, honest-to-goodness, public IP address, such as 2001:0DB8::1, and ensures that all traffic with 2001:0DB8::/32 IP addresses is stopped at one's borders.
The reason to use RFC 1918 addresses for IP version 4 is not that they are "non-routable". In practice, they are. The reason is that it is difficult to come by public IP version 4 address space.
If IP version 6 address space is easy to come by, it is preferable to use public IP addresses rather than "site local" or "(probably) unique local" addresses, and to employ proper firewalling at the organization borders. (After all, the mechanisms that prevent traffic with "site local" and "(probably) unique local" addresses from leaking across borders can be configured to prevent traffic with particular public IP addresses from leaking across borders just as easily.) This is because it avoids some of the problems alluded to in RFC 1918 § 4, and the problems caused by IP traffic tunnelling between two private networks, which are especially acute for proxy DNS servers and proxy HTTP servers.
It is best to stop traffic at border routers. Simply stopping traffic with a firewall on the server machine itself is merely a special case of the access control fallacy. Of course, border routers themselves do work in response to datagrams sent by attackers. But such work usually protects whole groups of machines and services in one fell swoop; stopping such traffic at borders prevents impersonation of interior clients by outsiders; stopping such traffic at borders prevents denial of service attacks by outsiders consuming interior network bandwidth; and stopping such traffic at borders prevents it from causing interior machines to do work on top of the work that the routers do anyway.