Web代理的介绍
Web代理服务器是网络的中间实体。代理位于客户端和服务器之间，是属于一种“中间人”角色，来两者之间来回传送HTTP保温。实际上：Web代理的工作职责就是代替客户端来和服务器进行交流，也就是说，客户端和Web代理进行对话，而后Web代理代表客户端和服务器进行通信。
Web代理既是Web服务器也是Web客户端。HTTP客户端会像Web代理发送HTTP请求报文，代理必须像真正的服务器一样，正确地处理HTTP连接和请求，然后返回响应。同时代理要向服务器转发客户端的HTTP请求，并接收响应。因此Web代理必须严格遵守HTTP协议。
代理与网关的对比
最终的区别是代理和客户端之间必须使用一致的协议，如HTTP协议。而网关则不一样，网关与客户端之间不一定要使用相同的协议。比如邮件发送服务，客户端与网关之间使用HTTP通信，然后网关再讲HTTP协议转为POP协议，与邮件服务器进行通信。
代理是如何获取流量的
修改客户端
通过修改客户端的配置，将客户端的流量直接发送到代理服务器中。
修改网络
可以通过网络基础设施，在客户端不知情的情况下，对客户端的流量进行拦截导入到代理中。
修改DNS命名空间
放在Web服务器之前的代理服务器的替代物，会直接假扮Web服务器的名字和IP地址，这样所有的请求都会发送到这个替代物中，而不是真正服务器。
修改Web服务器
也可以为服务器配置305重定向，将流量直接重定向到代理中。
代理相关的问题
代理URI与服务器URI的不同
代理和服务器的报文是一样的。不同在于URI上，代理必须是完整的URI，而直接对服务器的则不需要。原因在于：一开始的HTTP设计的时候，是直接客户端与服务器通信的，不存在“中间人”这一角色，因此服务器与客户端之间并不需要完整的URI。但是如果加入了代理后，这时候客户端是借由代理与和服务器通信的，这时候就必须标明完整的URI，以此知道目标服务器是谁。
代理既可以处理代理请求，也可以处理服务器请求
由于将流量重定向到代理服务器的方式有所不同，通用的代理服务器既应该支持请求报文中的完整URI,也应该支持部分URI。如果是显式的代理请求，代理就应该使用完整URI,如果是Web服务器请求，就应该使用部分URI和虚拟Host首部。
规则如下：
- 如果提供的是部分URI,而且有Host首部，就应该用Host首部来确定原始服务器的名字和端口号。
- 如果提供的是部分URI,而且有Host首部，就应该用Host首部来确定原始服务器的名字和端口号。
如果提供的是部分URI,而且没有Host首部，就要用其他方法来确定原始服务器
- 如果代理是代表原始服务器的替代物，可以用真实服务器的地址和端口号来配置代理;
- 如果流量被拦截了，而且拦截者也可以提供原始的IP地址和端口，代理就可以使用拦截技术提供的IP地址和端口号
- 如果所有方法都失败了，代理没有足够的信息来确定原始服务器，就必须这回一条错误报文(通常是建议用户升级到支持Host首部的现代浏览器)。
转发时对URI的修改
代理服务器要在转发报文时修改请求URI的话，需要特别小心。对URI的微改，甚至是看起来无害的修改，都可能给下游服务器带来一些互操作性问题。
URI的客户端自动扩展和主机名解析
根据是否有代理，浏览器对请求URI的解析会有所不同。没有代理时，浏览器会教取你输人的URI,尝试着寻找相应的IP地址。如果找到了主机名，浏览器会尝试椎应的IP地址直到获得成功的连接为止。
但是，如果没有找到主机，很多浏览器都会尝试着提供某种主机名自动“扩展”机制，以防用户输入的是主机“ 简短”的缩写形式。如：www.fishelly.top与fishelly.top的形式。
追踪报文
现在，将Web请求从客户端传到服务器的路径上，经过多个代理是常见的事情。因此在这个过程中能够回溯代理路径是很有必要的，我们需要追踪经过的代理的报文流，以检测出各种问题。
Via首部
Via首部列出了与报文途径的每个中间节点（代理或网关）的相关信息。报文每经过一个节点，都必须将这个中间节点添加到Via列表的结尾。
Via: 1.1 some-proxy0.com, 1.0 some-proxy1.com
详见：Via首部
上面标示报文经过了2个代理，分别是使用HTTP1.1协议的some-proxy0代理和使用HTTP1.0协议的some-proxy1代理。
TRACE方法
代理服务器可以在转发报文时对其进行修改。可以添加，修改或删除首部，也可以将主体部分转换成不同的格式。代理变得越来越复杂，互操作性问题也开始逐渐显现。为了方便于对代理网络进行诊断，查看在整个代理过程的报文变化，我们需要使用TRACE方法：用户可以追逐代理链传输的请求报文，观察报文经过了哪些代理，以及每个代理是如何对请求报文进行修改的。