一個基于瀏覽器端 JS 實現的在線代理

jsproxy

jsproxy是一個科學的在線代理項目，可實現例如Google/谷歌鏡像等的類似服務，有更多的定制設定和節能一鍵安裝等操作。

jsproxy功能特點

服務端開銷低

傳統在線代理幾乎都是在服務端替換 HTML/JS/CSS 等資源中的 URL。這不僅需要對內容做大量的分析和處理，還需對流量進行解壓和再壓縮，消耗大量 CPU 資源。并且由于邏輯較復雜，通常使用 Python/PHP 等編程語言自己實現。

為降低服務端開銷，本項目使用瀏覽器的一個黑科技 —— Service Worker。它能讓 JS 攔截網頁產生的請求，并能自定義返回內容，相當于在瀏覽器內部實現一個反向代理。這使得絕大部分的內容處理都可以在瀏覽器上完成，服務器只需純粹的轉發流量。

API 虛擬化

傳統在線代理大多只針對靜態 URL 的替換，忽視了動態 URL 以及和 URL 相關的網頁 API。例如 a.com 反向代理 google.com，但頁面中 JS 讀取 document.domain 得到的仍是 a.com。這可能導致某些業務邏輯出現問題。

為緩解這個問題，本代理在頁面頭部注入一個 JS，用以重寫絕大部分和 URL 相關的 API，使得頁面中的 JS 獲取到的仍是原始 URL：

對于有些無法重寫的 API，例如 location，本代理會將代碼中字面出現的 location 替換成 __location，從而將操作轉移到自定義對象上。當然對于非字面的情況（例如 this['lo' + 'cation']），目前還無法處理。

因此本項目服務端直接使用 nginx，并且轉發過程不修改內容（只修改 HTTP 頭），避免了內容處理產生的巨大開銷。同時得益于 nginx 豐富的功能，很多常用需求無需重新造輪子，通過簡單配置即可實現。并且無論性能還是穩定性，都遠高于自己實現。

服務端則直接利用 nginx 反向代理功能，并且不修改內容（只修改 HTTP 頭），避免處理內容的開銷，以及原始數據解壓再壓縮的開銷（或者不壓縮時流量開銷）。

例如現在流行的 br 壓縮，壓縮比高但壓縮成本很大。因此讓代理服務器只轉發而不操作數據，可節省大量資源。

jsproxy代理將不同的目標站點作為獨立的子域名，例如：

so.jsproxy.tk  =>  stackoverflow.com
gk.jsproxy.tk  =>  www.google.com

這在一定程度上隔離了站點之間的數據，例如 Cookie、Storage 等。

安裝部署

一鍵自動部署

curl https://raw.githubusercontent.com/EtherDream/jsproxy/0.1.0/i.sh | bash

自動安裝目前只支持 Linux x64，并且需要 root 權限
安裝過程中 80 端口能被外網訪問（申請 HTTPS 證書）
無法滿足上述條件，或想了解安裝細節，可嘗試手動安裝。

自定義域名

首先需要一個域名，例如 example.com，解析 @ 和 * 到服務器 IP。

curl https://raw.githubusercontent.com/EtherDream/jsproxy/master/i.sh | bash -s example.co

使用GitHub Pages 前端

本項目支持前后端分離，前端部分（www 目錄下的文件）可部署在第三方 Web 服務器上。

例如演示站點的前端部署于 GitHub Pages 服務，從而可使用個性域名（*.github.io），還能減少一定的流量開銷。

Fork 本項目，進入 gh-pages 分支（該分支內容和 www 目錄相同），編輯 conf.js 文件：

節點列表（node_map 字段，包括節點 id 和節點主機）
默認節點（node_default 字段，指定節點 id）

訪問 https://用戶名.github.io/

維護

# 切換到 jsproxy 用戶
su - jsproxy

# 重啟服務
./run.sh reload

# 關閉服務（參數和 nginx -s 相同）
./run.sh quit

# 啟動服務
./run.sh

# 查看代理日志
tail server/nginx/logs/proxy.log

下載地址：https://github.com/EtherDream/jsproxy