在企业内网、要经过代理网关，或者处于测试用的隔离环境里，BurpSuite没办法直接连到目标网站的时候，就需要去配好上游代理。很多人在问BurpSuite里面怎么配置上游代理，以及配完之后如果认证一直失败该怎么排查，这里面最关键的一点，是得把“浏览器到Burp”、“Burp到上游代理”、“上游代理到目标站点”这三段链路分开来看清楚，如果前一段走不通，Burp就根本抓不到任何流量；要是后一段卡住了，Burp虽然能把请求抓到，但目标站点那边却访问失败。

　　一、BurpSuite怎么配置上游代理

　　上游代理指的是Burp自己要往外转发请求时挂靠的那一个代理，这和浏览器本地设的那个代理不是一码事；浏览器依然要把请求指向Burp自己的监听端口，然后Burp再把这些请求转交给公司代理或者跳板代理。

　　1、打开上游代理的设置页面

　　进到BurpSuite以后，点击【Settings】或者【User options】，在里面找到【Network】→【Connections】→【Upstream proxy servers】这个位置，不同版本的界面名称多少会有一点点变化，不过它都在跟网络连接相关的设置区域里，找起来不算困难。

　　2、新增一条代理规则

　　点击【Add】按钮，然后在弹出的窗口里填好Destination host这一项；假如所有的请求都想走同一个上游代理，那就填成通配的格式；如果只是想让某个特定的域名走代理，那就填那个目标域名，或者按域名规则来写，这样做能够避免把全部流量都一把抓到不需要的代理上去，特别是内部的一些地址就不该往外绕一圈了。

　　3、把代理的地址和端口填上去

　　接着在Proxy host和Proxy port这两栏里填清楚上游代理服务器的地址和端口，比方说公司提供的HTTP代理或者测试用的网关地址；在往Burp里填之前，最好先拿浏览器或者系统自带的工具确认一下，这个代理本身到底能不能正常使用，确认通了再回到Burp这边做测试，省得在两边之间来回猜疑。

　　4、把认证用到的那套信息配好

　　如果上游代理要求提供账号和密码才能用，那就把认证相关的选项给勾上，然后老老实实地填好Username、Password还有认证类型；公司的域账号有时还得在前面加上域名前缀，格式到底怎么写，要跟企业代理要求的写法保持一致才行；保存好这些设置以后再重新去访问目标站点，同时观察Burp里面HTTP history的记录和弹出来的错误提示，看看报的是什么状态码。

　　二、BurpSuite上游代理认证失败怎么排查

　　遇到认证失败的时候，Burp通常还是能正常接收到浏览器发过来的请求的，只不过当它想把请求转给上游代理时被拒绝了；这时候不要光是一遍遍地改密码，更得先看一看看代理返回来的状态码，以及当前到底在用哪种认证方式。

　　1、先确认账号和密码有没有写对

　　找一个地方，用同样的账号放到浏览器的系统代理里去试一试，看能不能成功访问外网或者目标地址；如果连浏览器直接挂上游代理都访问不了，那就说明问题根本不在Burp身上，而是账号密码本身、代理权限或者网络策略出了事，得在这些方面找原因。

　　2、认真查一下认证类型是不是选对了

　　上游代理那边可能会用Basic、NTLM、Kerberos，或者其他企业常用的认证方式，要是在Burp里面把认证类型给选岔了，就算账号密码全对，验证也一样过不去；在域环境里尤其要确认好用户名的格式，是单纯地写用户名就可以了，还是得写成域名加用户名的样子，这点常常容易被忽略。

　　3、复查一下代理规则有没有匹配上

　　如果之前写的规则没能把目标地址给匹配进去，那么这个请求可能就根本没走你预期的那个代理出去；反过来，要是规则写得太宽泛，又容易把本来不该走代理的内部地址也一股脑儿地转发出去了；比较稳妥的法子是先只配置一个明确的域名来测试，等确认成功以后，再把规则的范围慢慢放宽。

　　4、看看代理那边是不是限制了客户端

　　企业的代理有时候会限制来源IP、限制具体的设备，或者限制用户组以及目标域名，所以换到另一台电脑、换一个网络环境，或者换一个账号，得到的结果可能完全不一样；一旦碰到407状态码、连接直接被拒掉，或者连接超时，就要结合代理那边给出的日志，去确认是不是被哪条策略给卡住了，很多信息都藏在日志里。

　　三、BurpSuite上游代理配置后怎么验证

　　上游代理全都配好以后，不能只看一个地方，要顺着链路一段一段地去验证，免得把浏览器代理出的问题、Burp自身监听出的问题，还有上游代理出的问题混在一起，那样排查起来就非常费劲了。

　　1、先确定浏览器能把请求送进Burp

　　打开Burp自带的浏览器，或者在外部浏览器里把代理指向Burp的监听地址，然后随便访问一个HTTP或者HTTPS的页面，瞧瞧【Proxy】→【HTTP history】里面能不能看到这个请求；要是根本看不到任何请求，那就先别想上游代理的事，先把浏览器代理的设置和证书的问题给排掉。

　　2、再确认Burp连上游代理是不是通的

　　如果HTTP history里已经有请求，但返回来的却是上游代理那边的错误码，这就说明浏览器到Burp这一段已经没问题了，问题出在Burp到上游代理这一段；这个时候就要把目光集中在认证信息、代理的地址端口还有代理规则上面，一段一段地核对。

　　3、检查一下HTTPS证书有没有捣乱

　　上游代理虽然已经配置成功了，可要是HTTPS的页面还是一直打不开，那就要回头去确认一下浏览器里到底有没有装好Burp的CA证书；有时候就是因为浏览器不信任这个证书，直接把连接给断掉了，而这种情况很容易被误认为是代理本身连不通，方向就走偏了。

　　4、把能正常运行的配置留下来

　　等确认整套代理能用之后，别忘了把Burp的项目文件给存一下，或者把用户配置单独导出；像企业代理的地址、认证的类型、还有那些例外的域名规则，都最好用文字记录下来，后面一旦换了机器，或者要重建一个新项目时，就能照着这些记录很快恢复出来，不用再从头摸索一遍。

　　总结

　　在BurpSuite里配置上游代理的时候，浏览器依然是连到Burp，Burp则通过Upstream proxy servers把请求转给企业代理或者测试代理；如果碰到认证失败的情况，先去验证账号密码本身有没有问题，再去检查认证的类型、域账号的书写格式、代理规则写没写对，以及企业代理那边有没有做额外的限制；排查的时候按着“浏览器到Burp、Burp到上游代理、上游代理到目标站点”这个顺序往下看，定位起来就会清楚得多，不至于在三段链路之间跳来跳去地乱猜。