在连接到代理后面的URL之前添加此选项。

System.getProperties().put("http.proxyHost", "someProxyURL");
System.getProperties().put("http.proxyPort", "someProxyPort");
System.getProperties().put("http.proxyUser", "someUserName");
System.getProperties().put("http.proxyPassword", "somePassword");

从Java文档(不是javadoc API):

http://download.oracle.com/javase/6/docs/technotes/guides/net/proxies.html

设置JVM标志http。proxyHost和http。在命令行上启动JVM时使用proxyPort。 这通常是在shell脚本(Unix)或bat文件(Windows)中完成的。下面是Unix shell脚本的示例:

JAVA_FLAGS=-Dhttp.proxyHost=10.0.0.100 -Dhttp.proxyPort=8800
java ${JAVA_FLAGS} ...

当使用JBoss或WebLogic等容器时，我的解决方案是编辑供应商提供的启动脚本。

许多开发人员都熟悉Java API (javadocs)，但很多时候忽略了文档的其余部分。它包含许多有趣的信息:http://download.oracle.com/javase/6/docs/technotes/guides/

更新:如果您不想使用代理来解析一些本地/内网主机，请查看来自@Tomalak的评论:

不要忘记http。nonProxyHosts财产!

-Dhttp.nonProxyHosts="localhost|127.0.0.1|10.*.*.*|*.example.com|etc"

You can utilize the http.proxy* JVM variables if you're within a standalone JVM but you SHOULD NOT modify their startup scripts and/or do this within your application server (except maybe jboss or tomcat). Instead you should utilize the JAVA Proxy API (not System.setProperty) or utilize the vendor's own configuration options. Both WebSphere and WebLogic have very defined ways of setting up the proxies that are far more powerful than the J2SE one. Additionally, for WebSphere and WebLogic you will likely break your application server in little ways by overriding the startup scripts (particularly the server's interop processes as you might be telling them to use your proxy as well...).

我认为配置WINHTTP也可以。

包括Windows更新在内的许多程序在代理后都有问题。通过设置WINHTTP总能解决这类问题

正如在其他回答中指出的那样，如果您需要使用经过身份验证的代理，纯粹使用命令行变量是没有可靠的方法来做到这一点的——如果您正在使用别人的应用程序，并且不想弄乱源代码，这是很烦人的。

Will Iverson在使用HttpProxy连接到具有抢先身份验证的主机上提出了有用的建议，使用代理管理工具如proxfier (http://www.proxifier.com/ for Mac OS X和Windows)来处理这个问题。

例如，使用proxfier，您可以将其设置为仅拦截要通过其(经过身份验证的)代理进行管理和重定向的java命令。在这种情况下，你需要将proxyHost和proxyPort的值设置为空，例如传入-Dhttp。proxyHost = -Dhttp。proxyPort=到您的java命令。

读取一个XML文件，并需要下载它的模式

如果您依赖于通过internet检索模式或dtd，那么您正在构建一个缓慢、频繁且脆弱的应用程序。当托管文件的远程服务器发生计划内或计划外停机时，会发生什么?你的应用程序崩溃了。这样可以吗?

看到http://xml.apache.org/commons/components/resolver/resolver-article.html s.catalog.files

模式和类似的URL最好被认为是唯一标识符。而不是远程访问文件的请求。在“XML目录”上做一些谷歌搜索。XML目录允许您在本地托管这些资源，从而解决了慢、多和脆弱的问题。

它基本上是远程内容的永久缓存副本。这是可以的，因为远程内容永远不会改变。如果有更新，也会是另一个网址。使得在互联网上实际检索资源变得特别愚蠢。