找回密码
 立即注册
首页 业界区 安全 关于代理这块

关于代理这块

谅潭好 2025-9-25 20:57:34
前言

简单写一下关于代理这一块的自定义的一些心得。
正文

一般情况下,我们使用nginx代理,这是反向代理。
然后有些情况下,我们需要正向代理,比如本地需要根据不同用户代理到不同的地区。
那么这个就需要我们自定义我们的代理。
这里用c#的一个库举例:Titanium.Web.Proxy
在了解到正向代理有两种,一个是代理中间人模式,一种是透传模式。
首先介绍一下透传模式:
在 透传代理(Forward Proxy) 模式下,Titanium.WebProxy 是否要求 被代理方(客户端或目标服务器)自行解密 HTTPS 流量,取决于代理的具体配置:

  • 透传 HTTPS 流量(不解密)
当设置 ForwardToUpstreamGateway = true 时:
代理行为:
代理仅作为 隧道(Tunnel),直接转发客户端的原始 HTTPS 流量到目标服务器。
不解析、不修改、不解密 HTTPS 内容。
客户端与目标服务器之间仍保持端到端加密。
被代理方的解密责任:
客户端:需要自行完成 TLS 握手(如浏览器验证服务器证书、协商密钥)。
目标服务器:需要正常解密客户端发送的 HTTPS 请求。
性能影响:
代理无加解密开销,性能接近直接连接。
适用于仅需转发流量、无需监控或修改内容的场景。
这种情况呢,这种情况就是建立了两个tcp,一个tcp来数据了直接丢给另外一方。
我们来看下它是如何建立这个两个连接的。
首先客户端发起connect 代理请求来验证,
然后代理方进行验证后,和connect的host服务器进行建立隧道,简单理解为建立tcp连接吧。
然后这个时候代理方就会返回给客户端代理成功了。
这时候就打通隧道了。后面客户端就直接可以和服务器通信了。
如果遇到根据不同用户需要转到不同的代理,那么在connect的时候,就不建立到host服务器的连接,而是建立和下一级代理服务器的连接。
  1. proxyServer.BeforeRequest += (sender, e) =>
  2. {
  3.     if (e.HttpClient.Request.Method == "CONNECT")
  4.     {
  5.         e.CustomUpstreamProxy = new ExternalProxy
  6.         {
  7.             Host = GetSecondaryProxyByUser(e.HttpClient.Session.SessionId),
  8.             Port = 8080
  9.         };
  10.         e.DisableInterception = true; // 保持透传
  11.     }
  12. };
复制代码
二级代理的要求:
  1. proxyServer.BeforeRequest += (sender, e) =>
  2. {
  3.     if (e.HttpClient.Request.Method == "CONNECT")
  4.     {
  5.         e.CustomUpstreamProxy = new ExternalProxy
  6.         {
  7.             Host = GetSecondaryProxyByUser(e.HttpClient.Session.SessionId),
  8.             Port = 8080
  9.         };
  10.         e.DisableInterception = true; // 保持透传
  11.     }
  12. };
复制代码
当建立connect的时候,设置CustomUpstreamProxy ,那么就会连接到下一级代理。
这就是透传模式,建立两个tcp进行转发,就像一条隧道一样。
这就是https的透传,那有没有http透传呢?
但是好像没有怎么听到http透传呢? 这是怎么回事呢?
首先达到http透传是可以实现的,只要不拦截,其实是http是一致的。
  1. Get example.com HTTP/1.1
  2. Host: example.com
  3. Proxy-Authorization: Basic dXNlcjpwYXNz  # 代理认证(可选)
复制代码
如果http 是长连接的话,也是第一个需要带上Proxy-Authorization,其他时候不需要认证,那么其实是可以和https一样可以达到隧道的效果的。
那么为什么http 大多数时候不做隧道,而做拦截呢?
  1. 可以但不实用:
  2. HTTP 代理技术上可以不解析请求,但会失去核心价值,仅适用于极简场景。
  3. 设计权衡:
  4. HTTP 的明文特性与代理功能的强耦合,使得解析成为默认选择。
  5. 替代方案:
  6. 如需完全透传,应使用隧道(如 CONNECT)或原始 TCP 代理,而非 HTTP 代理。
复制代码
1.png

MITM 中间人代理模式。
就是捕获到流量后,根据请求,自己请求后,然后返回给客户端。


简单介绍一下。

来源:程序园用户自行投稿发布,如果侵权,请联系站长删除
免责声明:如果侵犯了您的权益,请联系站长,我们会及时删除侵权内容,谢谢合作!

相关推荐

您需要登录后才可以回帖 登录 | 立即注册