SQLite不能直接走HTTP隧道,因其是嵌入式数据库,无服务端进程,不监听网络端口也不解析HTTP请求;所有“HTTP访问”均需上层Web服务封装并配合隧道工具实现。
SQLite 不能直接走 HTTP 隧道
sqlite 是嵌入式数据库,没有服务端进程,sqlite3 库直接读写文件。它本身不监听网络端口,也不理解 http 请求——所以不存在“用 http 隧道连 sqlite”的原生路径。所有所谓“绕过防火墙连 sqlite”,实际都是在 sqlite 上层加了一层代理或 web 封装。
常见可行方案:用轻量 Web 服务暴露 SQLite 接口
真正能落地的做法,是起一个本地 Web 服务(比如用 Python 的 Flask 或 Node.js 的 express),把 SQL 查询封装成 HTTP API,再用反向代理或隧道工具(如 ngrok、cloudflared)暴露出去。
- 必须自己实现权限控制,
/query?sql=...这类接口不加校验等于裸奔 -
sqlite3默认不支持并发写入,多个 HTTP 请求同时INSERT可能触发database is locked - 别把
db.sqlite3文件放在 Web 根目录下,否则可能被直接下载(例如 Nginx 默认不解析.sqlite3后缀) - 示例片段(Flask):
from flask import Flask, request, jsonify import sqlite3 app = Flask(__name__) @app.route('/query') def run_query(): sql = request.args.get('q') if not sql or 'insert' in sql.lower(): # 简单拦截,不可靠 return jsonify({'error': 'forbidden'}), 403 conn = sqlite3.connect('app.db') cur = conn.cursor() cur.execute(sql) rows = cur.fetchall() conn.close() return jsonify(rows)
ngrok / cloudflared 隧道配置要点
这类工具只是把本地端口映射到公网 URL,不关心你跑的是什么服务。但容易出问题的地方很具体:
-
ngrok http 5000要确保你的 Web 服务确实在localhost:5000监听,而不是127.0.0.1:5000(某些框架默认只绑本地回环) - 免费版
ngrok的域名每小时轮换,硬编码在前端会断;cloudflared tunnel需提前配好config.yml和tunnel id - HTTP 隧道无法穿透双向认证或企业级防火墙的深度包检测(DPI),遇到返回
ERR_TUNNEL_CONNECTION_FAILED就得换协议(比如改用 WebSocket 封装) - 别在隧道 URL 里传敏感参数,
GET请求的sql=...会明文留在代理日志、浏览器历史、CDN 缓存里
为什么不用 WebAssembly + SQLite?
有人提过用 sql-wasm 在浏览器里直接操作 SQLite 文件,听起来像“绕过服务端”。但它只适用于前端已拿到完整 DB 文件的场景:
- 首次加载需下载几 MB 的 WASM 模块,慢且不可缓存
- 无法执行
PRAGMA journal_mode = WAL等需要文件系统权限的操作 - 浏览器同源策略限制,
fetch('db.sqlite3')会失败,除非后端显式设置CORS头 - 真要这么做,不如直接用 IndexedDB —— 它原生支持结构化查询、事务、离线,还不用传整个 DB 文件
真正卡住的从来不是技术拼接,而是权限模型和数据流向。SQLite 文件一旦离开本地磁盘,就不再是 SQLite 了。











