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 了。
