15. 安全与调试 - Jesse 速读教程

走到这一步，策略已经开发完成，回测结果令人满意，实盘配置也准备就绪。但在真正让资金跑起来之前，还有最后两道关卡必须认真对待：安全与调试。这不仅是技术问题，更是责任问题。毕竟，我们面对的是真实的资金流动和潜在的网络威胁。

Jesse 作为自托管的交易系统，安全责任完全在我们自己肩上。好在它的设计哲学是"不面向公众"，这大大简化了安全防护的复杂度。我们不需要像运营一个网站那样考虑 DDoS 攻击、SQL 注入等五花八门的威胁，只需要确保自己能在需要时安全访问，同时把不该泄露的信息牢牢锁好。

仪表板密码安全

Jesse 的敏感配置都集中存放在项目根目录的 .env 文件里。这个文件默认包含了一些基础设置，其中最重要的就是 PASSWORD 字段。默认密码是 test，这显然不能用在生产环境。

PASSWORD=test
APP_PORT=9000

修改密码非常简单，直接用文本编辑器打开 .env 文件，把 test 替换成一个足够复杂的字符串即可。建议使用密码生成器服务生成至少 16 位的随机密码，包含大小写字母、数字和特殊字符。别用生日、宠物名字或者任何能在字典里找到的单词，那些都太容易被猜到了。

修改完成后，需要重启 Jesse 服务才能让新密码生效。如果是在 Docker 环境中，先执行 docker-compose down，修改文件后再 docker-compose up -d。非 Docker 环境则直接重启应用进程。

这里有个细节值得注意：.env 文件里除了密码，还存放着数据库连接信息、Redis 配置，以及后面会讲到的交易所 API 密钥。这个文件必须加入 .gitignore，绝对不能提交到版本控制系统。一旦泄露，后果可能比密码被破解更严重。

UFW 防火墙配置

密码保护是第一道防线，防火墙是第二道。Jesse 的仪表板默认运行在 9000 端口，SSH 服务运行在 22 端口。我们的目标是：只允许特定 IP 地址访问这两个端口，其他所有入站请求一律拒绝。

UFW 基础操作

UFW（Uncomplicated Firewall）是 Ubuntu 系统自带的防火墙工具，语法简洁明了。首先检查当前状态：

ufw status

如果显示 active，建议先停用它，避免配置过程中把自己锁在外面：

systemctl stop ufw

接下来设置默认策略：允许所有出站流量，拒绝所有入站流量。这是防火墙配置的黄金法则，能最大限度减少攻击面。

ufw default allow outgoing
ufw default deny incoming

然后开放 SSH 端口，确保我们还能远程登录服务器：

ufw allow ssh

这一步至关重要。如果先启用防火墙再开放 SSH 端口，可能会瞬间失去与服务器的连接。UFW 的 ssh 规则会自动映射到 22 端口，相当于执行了 ufw allow 22/tcp。

限制仪表板访问

现在到了关键部分：限制 9000 端口只能被我们的 IP 访问。假设我们的公网 IP 地址是 203.0.113.45，执行：

ufw allow from 203.0.113.45 to any port 9000 proto tcp

这条命令的意思是：只允许来自 203.0.113.45 的 TCP 协议流量访问本机的 9000 端口。proto tcp 明确指定协议类型，虽然 UFW 默认就是 TCP，但显式声明更稳妥。

如果有多个需要访问的 IP，重复执行上述命令即可。比如家里和公司都需要访问：

ufw allow from 203.0.113.45 to any port 9000 proto tcp
ufw allow from 198.51.100.23 to any port 9000 proto tcp

配置完成后，启用防火墙并检查规则：

ufw enable
ufw status numbered

ufw enable 会提示可能会中断现有连接，确认即可。status numbered 会显示带编号的规则列表，方便后续管理。如果需要删除某条规则，使用 ufw delete [编号] 即可。

最后重启 UFW 确保所有配置生效：

systemctl restart ufw

Docker 环境的特殊处理

这里有个大坑：UFW 和 Docker 的兼容性不太好。Docker 会直接操作 iptables，可能会绕过 UFW 的规则。如果使用的是 Docker 部署，更推荐用数据中心提供的防火墙服务。

以 Hetzner 为例，登录控制台，进入服务器的 Firewalls 标签页，点击 CREATE FIREWALL。先查询本机公网 IP，然后创建两条规则：

SSH 规则：Protocol 选 TCP，Port 填 22，Source 填你的 IP
Dashboard 规则：Protocol 选 TCP，Port 填 9000，Source 填你的 IP

这样配置的好处是 IP 变更后可以在网页端随时修改，不需要登录服务器。而且数据中心的防火墙在流量到达服务器之前就已经过滤，效率更高。

DigitalOcean、AWS、阿里云等主流云服务商都提供类似的防火墙服务，配置逻辑大同小异。关键是记住最小权限原则：只开放必要的端口，只允许信任的 IP。

交易所密钥保护

.env 文件的后半部分密密麻麻全是交易所 API 密钥的配置。从 Binance 到 Bybit，从 Bitget 到 dYdX，每个交易所都提供了测试网和主网的密钥对。

# Binance Futures
BINANCE_PERPETUAL_FUTURES_API_KEY=
BINANCE_PERPETUAL_FUTURES_API_SECRET=

# Bybit USDT Perpetual
BYBIT_USDT_PERPETUAL_API_KEY=
BYBIT_USDT_PERPETUAL_API_SECRET=

这些密钥的敏感程度远超登录密码。API Key 和 Secret 一旦泄露，攻击者就能完全控制我们的交易账户，包括下单、撤单、甚至提币（如果开启了提币权限）。因此必须做到：

第一，为 Jesse 创建专用的 API 密钥，不要复用在其他地方的密钥。这样即使泄露，影响范围也有限。

第二，在交易所后台配置 IP 白名单。大多数交易所都支持限制只有特定 IP 才能使用该 API 密钥。把我们服务器的公网 IP 加进去，这样即使密钥泄露，攻击者也无法从其他 IP 调用。

第三，不要给密钥不必要的权限。如果策略只需要交易，就不要开启提币权限。测试网密钥可以宽松一些，主网密钥必须严格限制。

第四，定期轮换密钥。建议每 3 个月更换一次 API Secret，降低密钥被长期盗用的风险。

第五，.env 文件的权限设置为 600，只允许当前用户读写：

chmod 600 .env

这样即使服务器上有其他用户，也无法读取我们的密钥。

调试模式激活

策略开发过程中，最耗时的不是写代码，而是找 bug。Jesse 提供了专门的调试模式，能记录策略执行的每一个细节。

在仪表板的设置页面（右上角齿轮图标），找到 Debug Mode 选项并启用。开启后，每次回测都会生成详细的日志文件，记录 Jesse 的每一步操作：从 K 线数据读取到指标计算，从信号触发到订单执行。

# 示例：策略中的日志输出
def should_long(self):
    self.log(f"当前收盘价: {self.close}")
    self.log(f"MA10: {self.sma10}, MA20: {self.sma20}")
    return self.crossover(self.sma10, self.sma20)

调试模式对回测性能影响明显，执行时间会增加数倍。因此只在排查问题时临时开启，平时保持关闭。但对于实盘交易，建议一直开启。实盘的数据流是实时到来的，日志记录不会明显影响性能，反而能在出问题时提供宝贵的排查线索。

日志的详细程度可以在设置页面的 Logs 部分调整。可以选择记录哪些模块的输出，比如只关注订单执行相关的日志，或者只看风险管理相关的日志。灵活配置能避免信息过载。

日志文件检查

日志是调试的基石。Jesse 的日志系统分为两类：会话日志和原始数据流日志。

会话日志

每次回测或实盘会话都会生成独立的日志文件，存放在 storage/logs/{mode}/{session_id}.txt。{mode} 是运行模式，比如 backtest 或 live，{session_id} 是唯一的会话标识符。

日志文件采用纯文本格式，可以用任何文本编辑器打开。内容按时间顺序排列，包含：

系统初始化信息
数据加载进度
指标计算结果
策略决策过程
订单提交与执行
仓位变化
风险管理操作

在策略代码中，可以使用 self.log() 方法输出自定义信息。这相当于 Python 的 print()，但输出会被正确格式化并写入日志文件。

def update_position(self):
    # 调试止盈逻辑
    self.log(f"当前盈亏: {self.position.pnl_percentage}%")
    self.log(f"持仓时长: {self.position.holding_period} 根K线")
    
    if self.position.pnl_percentage > 5:
        self.log("触发止盈条件，准备平仓")
        self.liquidate()

上面的代码会在日志中输出三条记录。如果策略没有按预期平仓，查看日志就能知道是 pnl_percentage 没达到 5%，还是 liquidate() 没被调用。

实时日志查看

实盘运行时，不需要等会话结束才能看日志。仪表板上有 "Info Logs" 按钮，点击后会弹出实时日志窗口，显示最近几百条日志记录。这对监控策略运行状态非常有用。

窗口中的日志是实时刷新的，能看到最新的决策逻辑和订单状态。如果发现异常，可以立即介入处理。

原始数据流日志

实盘模式下，Jesse 还会记录交易所推送的原始数据流，存放在 storage/logs/exchange-streams.txt。这个文件每次启动新会话时会被覆盖，只保留当前会话的数据。

数据流日志包含交易所发来的每一条消息：行情更新、订单状态变化、仓位信息推送等。当怀疑是交易所数据问题时，这个文件就是第一手证据。

日志分析技巧

看日志要有方法，否则会被海量信息淹没。建议关注几个关键点：

时间戳：确认事件发生的顺序是否符合预期
价格数据：检查策略接收到的价格是否与市场一致
决策点：找到 should_long、should_short 等方法的调用记录
订单状态：从提交到成交的完整链路是否通畅
错误信息：搜索 ERROR 或 Exception 关键字

对于复杂的策略，可以在关键节点添加标记性的日志输出：

def before(self):
    self.log("=" * 50)
    self.log(f"新K线到达: {self.time}")
    self.log("=" * 50)

这样能快速定位每根 K 线的处理过程。

总结

从第 1 章的环境搭建，到这一章的安全调试，我们已经走完了 Jesse 量化交易的完整旅程。这十五个章节构建了一个从入门到实战的知识体系，涵盖了策略开发、回测分析、风险管理、实盘部署的方方面面。

量化交易不是简单的技术指标堆砌，而是一个系统工程。它要求我们既要懂编程，又要懂金融；既要能设计策略，又要能评估风险；既要追求收益，又要控制回撤。Jesse 为我们提供了强大的工具，但工具的价值取决于使用者的认知深度。

安全与调试是最后一道防线，也是最重要的防线。再优秀的策略，如果因为安全漏洞导致密钥泄露，或者因为调试不足导致逻辑错误，都可能带来灾难性后果。这一章的内容看似琐碎，实则是保护我们心血成果的护城河。

回顾全书，几个核心思想贯穿始终：

数据为王：从第 3 章的市场数据管理到第 12 章的研究工具，高质量的数据是所有分析的基础。垃圾进，垃圾出，这是量化领域永恒不变的真理。

简单有效：第 8 章的性能优化和第 11 章的过拟合预防都在提醒我们，复杂的模型不一定更好。在样本内表现完美的策略，往往在样本外不堪一击。稳健性比收益率更重要。

风险第一：第 9 章的仓位与风险管理、第 10 章的策略优化、第 11 章的验证方法，共同构建了一个完整的风险控制框架。活着，才能赚钱。

循序渐进：从回测到纸交易，再到小资金实盘，最后扩大规模。每一步都要验证，每一步都要谨慎。第 13 章和第 14 章的实盘配置与监控，为这个过程提供了技术保障。

量化交易是一场马拉松，不是百米冲刺。它考验的不是一时的灵感，而是持续的迭代能力、严谨的风险意识和稳定的心理素质。Jesse 降低了技术门槛，但无法降低认知门槛。真正的护城河，永远是我们的学习能力和对市场的理解。

希望这套教程能帮你建立起完整的知识体系，但更重要的是，希望你能保持好奇心和批判性思维。市场永远在变，策略会失效，模型会过时，但正确的思维方式和学习习惯，会让我们始终走在进化的路上。

祝交易顺利，我们市场见。