友人跟我说，他试了几个『浏览器科学插件』，不是已经死了，就是没多久就死了

——好像也是，笔者也用过一段时间的浏览器插件来科学上网，虽然还不至于是红杏这个年代，但是也用过skyZIP，他们的结局，无一例外就是，最后（尤其是这几年）死得特别快

既然友人问起来，那在解答的同时，其实也不妨拿出来谈谈了

笔者手头有几个此类浏览器插件，包括一直保存至今的skyZIP。因为Chrome扩展本质就是一个ZIP压缩包，因此只需要改扩展名为zip，然后就可以直接解包

这类插件基本上都已经是七八年前的事情了，全部都是MV2规范的（Chrome的MV3是真不干人事），程序本体基本上就是那几个js文件，笔者把关键部分摘录如下，关键部分打码（因为部分硬编码地址的服务器，已经被他人买走了），看看各位是否发现什么端倪：

常见例子

『X加速』

// js/app.js

SERVER = '45.*.*.245:8081/freesea';
API_URL = "ws://localhost:8081";
LOG_URL = "http://log." + SERVER + ":8888/log";

GUEST_DOMAINS = ['facebook.net','facebook.com', 'fbcdn.net']//太长，不列出
WHITE_LIST_DOMAINS = [SERVER] //太长，不列出

// js/login.js

$http.post("http://" + SERVER + "/user/login",{
    username:$rootScope.name,
    password:$scope.password
}).success(function(resp) {
    /*太长，不列出*/
});

// js/services/proxyManger.js

chrome.proxy.settings.set({
    value: {
        mode: 'pac_script', pacScript: {
            data: "function FindProxyForURL(url, host) { var D = 'DIRECT';var p='https xxxxxx:443';return D;}"
        }
    },
    scope: 'regular'
}, (function () {
    return function () {
        return null
    }
})(this))

skyZIP

官网已死，有事烧纸

这个笔者用的比较多，基本上断断续续撑过了初中前两年时间

// background.js
var availableServers = [
  'default.px.skyzip.de',
  '3.px.skyzip.de',
  '4.px.skyzip.de'
];

chrome.proxy.settings.set({
  value: {
    mode: 'fixed_servers',
    rules: {
      proxyForHttp:{
        scheme: 'https',
        host: httpServer.host,
        port: httpServer.port
      },
      proxyForHttps: {
        scheme: 'https',
        host: httpsServer.host,
        port: httpsServer.port
      },
      bypassList: bypassList
    }
  },
  scope: 'regular'
});

xxx谷歌学术助手

很多科学插件都打折『谷歌助手』的名号，当然也有部分真的只提供谷歌访问功能
十几年前可能还比较好用，但是在谷歌搜索结果一堆被墙了的今天，意义反倒是不太大了

// js/***service.js

***cfg.mzk_backup_server = [
    "https://$udomain$.*****.net/",
    "http://$udomain$.*****.com/",
    "http://$udomain$.*****.net/",
    "http://****.fyi/",
    "https://$udomain$.******.com/",
    "http://v5.******.com:8801/",
    "http://service.*****.xyz:10911/",
];


// js/settings.js
class Mzk_Chrome_proxy {
    applyChanges(config, cb) {
        chrome.proxy.settings.set({
           value: config,
           scope: 'regular'
      }, cb);
    }}

/* 太长不列出 */
}

Ultras*rf

为了避免博客被炸，这里也打个码

对，就是轮子那个，同时也是笔者研究比较多的，主要是其中存在一个神奇的，向内网地址10.11.0.2:7000的访问请求，其中附带了登录时间，浏览器MV版本等参数。笔者曾经在无干扰网络环境下，挂上里面提供的代理，构造正确参数去访问这个地址，返回HTTP 503，无法确定是已下线还是做做样子

这玩意和skyZIP一样，扩展内部硬编码了一个HTTPS代理服务器列表（注意这里的硬编码，后面还要再提），而且....得益于这帮狗腿子背后的势力，这些代理服务器都是存活的，而且没有鉴权，完全一副『小帅哥快来白嫖呀』的感觉

$ dig +short jimmywok.site
65.49.2.35
65.49.68.172
65.49.2.58

$ curl -x "https://jimmywok.site:443" ip.sb
64.62.219.63

# 查过ipinfo.io，这个IP居然是双ISP（也就是所谓的纯正家宽IP）

$ openssl s_client -connect jimmywok.site:443
CONNECTED(00000003)
.......
depth=1 C = US, O = Let's Encrypt, CN = R11
verify return:1
depth=0 CN = jimmywok.site
verify return:1
.......

// assets/js/background/js/discovery.js

let hosts = [
"metalpressions.site",
"horseclicks.online",
"metalpressions.online",
"metalpressions.fun",
"horseclicks.site",
"seahorse-labs.site",
"seahorse-labs.online",
"leathavenhorst.site",
"leathavenhorst.online",
"bk-fonbet.website"
/* 这个硬编码的列表的剩余部分
占满了我的屏幕的垂直长度 */
]

原理分析

看完上面的代码，有点感受没？
他们都有一个共同的特点：

1. 采用HTTPS代理的方式，连接到海外代理服务器
2. 多数会通过API定期下发最新节点列表
3. 也有部分是硬编码服务器列表（多见于免费插件）

这三个特点都不是空穴来风的：

HTTPS代理

其实应该说，分两派：

• HTTP/HTTPS代理 + 境内服务器 + 安全通道出国
• HTTPS + 海外服务器直接出国

前者的代表作，据说是红杏，当然也不排除某些插件的『高级VIP线路』也会用到这种技术，因为有境内服务器对数据作收集，加密处理以及链路优化，出境段最次的也是Stunnel，甚至可能直接用的是SS（别忘了，在这些插件流行的时候，SS依然是主力军），所以访问效果非常好，响应速度也很给力。因为连接段不用过墙，所以HTTP代理也可以（但是隐私会有些问题）

但是，画重点，境内服务器，这就涉及到了三个问题，有可能导致这种链路挂掉：

1. 费用高：看过我上一篇文章的朋友都清楚，境内带有固定IP专线接入非常麻烦，带宽价格也是居高不下（当然如果你说有运营商内鬼，那不在讨论范围内，有内鬼啥都办得到），这就导致了境内服务器的成本也跟着上升，服务商不一定跑得过来
2. 跨境流量：以前可能问题不大，但是现在大流量的公网跨境中转（中转，主要是看你是不是出入近似相等）很容易引起管局注意，最后的结果基本上都是直接拔线
3. 备案：不知道你注意到没有，这玩意跑的可以是HTTP代理，妥妥的标准HTTP协议，虽然不在80端口，但是有些机房的全端口监控也可能被触发，阻断通信

基于以上种种麻烦，有些服务商转向了方案2。

笔者不是很清楚在这些玩意还流行的时候，HTTPS证书是怎么搞的，容不容易（至少上面的例子可以看到是Let's Encrypt的证书），但是可以明确的一点是：如果不考虑时序攻击等侧信道手段，以及判断包长之类的特殊手段，那么TLS之下众生平等。包裹在TLS里面的HTTP代理自然也就可以复活。

但是不确定你有没有发现一个问题：各类浏览器内置的必然是标准HTTP代理客户端，走的是标准的HTTP代理协议。这种情况下其实防不住主动探测（TLS无法解决这个问题，因为他只能防止第三方监听，而无法阻止第三方连接，除非你做双向认证）

举个例子，如果我看到example.com:9394有SSL流量，那么我也可以连接上去，然后发送：

CONNECT google.com:443 HTTP/1.1 

如果这是个开放代理，那么服务器此时应该接通谷歌，并返回：

200 Connection established

如果这个代理要求鉴权，那么就会返回

407 Proxy Authentication Required

并附带身份验证方法。

换句话说，不管你做不做身份验证，通过这个主动探测，标准的HTTP代理都会直接告诉客户端，我就是个代理。因此想要主动封禁这类代理服务器，简直是易如反掌

API 与 硬编码

表观上看，这种基本上就已经是机场模式的变体，只是他的协议变成了HTTP代理，而不是常用的SS/V2。而当今机场的订阅链接，则对应了浏览器扩展里面的API地址

首先要明白一点，浏览器扩展本质上就是服务商自己编写的客户端，因为是自己编写的，所以里面自然各种奇技淫巧都能用上，最基本的就是通过API定期获取最新节点地址

至于把成吨的节点服务器硬编码在插件内的，基本上多见于免费扩展（比如上面的USurf），好处是可以避免向中心服务器发出信息，降低了被追踪到的概率（有可能？）；当然坏处就是，更新节点就要更新整个扩展，如果里面的节点全部完了，那也完了。

结论

这一类『科学插件』（准确的说法是浏览器扩展）的核心工作原理，极大多数，可以说是给浏览器设置HTTP/HTTPS代理，但是这么做不可避免的会被主动识别，然后就挂了

当然更大的因素可能是背后有个不太靠谱的服务商

后记

怎么说呢，笔者在青涩年代也是用过这一类插件的
但是现在的话....只能说，敬 那段已经逝去的时光

（完）