从Vue代理到服务器监控：一个小团队的技术栈实战记录

当你的开发环境开始拖累团队效率

2026年过半，我所在的小团队经历了三轮迭代后，最痛的不是代码逻辑复杂度，而是开发环境和基础设施的割裂感。新来的后端同事把接口改了个路径，前端小伙伴调试到抓狂；服务器上跑了三个服务，谁都不知道哪台机器快要撑不住了。这些看似散落的问题，其实都指向同一个核心——技术栈的协同与可观测性。今天这篇记录，不讲大道理，只说我踩过的坑和最终沉淀下来的那套配置。

Vue 代理服务器 Proxy 配置

为什么官方文档解决不了你的跨域问题

大多数 Vue 项目初始化时都会配一个 vue.config.js，里面写几行 devServer.proxy 指向后端地址。但真正上线的环境里，后端服务可能分布在三个不同的端口上，甚至有的用了 WebSocket。我在 2026 年 3 月的版本迭代中遇到一个典型场景：前端通过代理转发到 http://localhost:3000，后端返回了 302 重定向到 http://localhost:3000/login，结果浏览器直接报跨域，因为重定向后的地址没走代理。

解决方案其实很简单：pathRewrite 加上 changeOrigin: true，但问题在于，很多团队不知道 ws: true 还要单独开。以下是我在 2026 年 6 月最后一次调整后稳定运行的配置模板：

module.exports = {
  devServer: {
    proxy: [
      {
        context: ['/api', '/ws'],
        target: 'http://192.168.1.100:3000',
        changeOrigin: true,
        ws: true,
        pathRewrite: { '^/api': '' }
      },
      {
        context: ['/auth'],
        target: 'http://192.168.1.101:4000',
        changeOrigin: true
      }
    ]
  }
}

这个配置最关键的改进是把多个后端服务分离成不同的 context，并且对 WebSocket 路径单独处理。另外，changeOrigin: true 在反向代理场景下一定要开，否则 host 头不对会触发后端的校验。

缓存服务器系统

别再用 Redis 当万能缓存了

2025 年我们团队把 Redis 当成了万能缓存，所有数据都往里塞，结果某些大 Key 导致集群抖动。到了 2026 年，我更倾向于按数据特征选择缓存系统：静态文件用 Nginx 的 proxy_cache + CDN，热点数据库查询用 Redis 且严格控制 TTL，而像会话状态这种频繁读写但容量小的，直接用 Memcached 反而更轻量。

实际部署时，我推荐一套组合拳：Nginx 层做静态资源缓存和 API 响应缓存，Redis 做业务层缓存。Nginx 的 proxy_cache 配置比很多人想象中灵活：

proxy_cache_path /data/nginx/cache levels=1:2 keys_zone=my_cache:10m max_size=1g inactive=60m use_temp_path=off;

这里 inactive=60m 比 TTL 优先级更高，如果 60 分钟没有被访问，缓存会被自动清理。配合 proxy_cache_bypass $http_pragma 可以强制刷新某个路径的缓存，非常适合静态资源更新后的刷新场景。

个人用服务器可以干什么

从玩具到生产力：我的家用服务器变迁史

去年我把一台退役的旧笔记本刷成了 Ubuntu Server，装上 Docker 后，它就跑起了几个关键服务：家庭 NAS（用 Nextcloud）、广告拦截（Pi-hole）和一个用来测试的 GitLab Runner。今年 4 月我增加了两个更实用的场景：

内网穿透替代品：搭配 Cloudflare Tunnel 把家里跑的小型 Web 应用暴露到公网，用于给远程办公的同事预览设计稿。比 ngrok 稳定，而且不限制流量。
离线 AI 模型推理：用 Ollama 跑一个 7B 参数的大模型，配合自建 RAG 系统，给我的个人博客做了个智能问答功能。虽然每句话要等两秒，但数据完全在自己手里。

个人服务器的核心价值不是性能，而是掌控感。你可以把零散的数字生活收拢到一个硬件上，按自己的规则运行。

云服务器如何使用 SFTP

安全地与云服务器传输文件

很多人在第一次使用云服务器时，总想着装个图形界面或者第三方工具来传文件。其实 SFTP 是 SSH 协议内建的能力，任何 Linux 服务器只要开启了 SSH，就能用 SFTP 直接传输文件。我见过太多团队在线上环境装 vsftpd 导致安全隐患的案例。

我自己常用的命令是：

sftp -i ~/.ssh/id_rsa user@your-server-ip

进入交互模式后，put local_file remote_path 上传，get remote_file local_path 下载。如果你需要批量传输，推荐用 rsync 基于 SSH 的用法：

rsync -avz -e "ssh -i ~/.ssh/id_rsa" /local/dir user@server:/remote/dir

2026 年新版的 OpenSSH 默认禁用了 SFTP 的密码登录，必须使用密钥认证。这对安全是好事，但如果你需要临时给别人用，可以用 Match User 在 sshd_config 里单独开放：

Match User sftpuser
    ChrootDirectory /home/sftpuser
    ForceCommand internal-sftp
    PasswordAuthentication yes

注意：ChrootDirectory 的所有者必须是 root，否则连接会被拒绝。这个坑我栽过一次。

服务器性能监控脚本

用简单的 shell 脚本做可观测性

很多团队一上来就上 Prometheus + Grafana，但对于只有三五台服务器的团队，它太重了。我写了一个不到 100 行的 shell 脚本，部署在所有服务器上后，配合一个简单的 HTTP 服务，就能实现基础监控。核心逻辑是：

每 30 秒采集 CPU、内存、磁盘、网络流量
如果 CPU 超过 80% 或者磁盘用满 90%，调用 webhook 发送告警到飞书
数据写入本地 CSV，保留最近 7 天，用于事后排查

脚本核心片段：

#!/bin/bash
CPU_USAGE=$(top -bn1 | grep "Cpu(s)" | awk '{print $2}' | cut -d'%' -f1)
MEM_USAGE=$(free | grep Mem | awk '{print $3/$2 * 100.0}')
if (( $(echo "$CPU_USAGE > 80" | bc -l) )); then
    curl -X POST -H "Content-Type: application/json" -d '{"msg":"CPU high"}' $WEBHOOK_URL
fi

这个脚本配合 cron 跑起来后，效果出奇的好。上个月它帮我发现一台服务器因为日志文件没有轮转，磁盘使用率从 60% 飙升到 98%，及时清理后避免了宕机。如果你追求更快的部署，可以跟 Netdata 结合：Netdata 负责实时图表，这个脚本只做告警和日志留存，分工明确。

结尾：技术债要还，但方法要对

回到开头那个问题：当开发环境、缓存系统、个人服务器、文件传输和监控这些看似无关的环节串联起来后，你会发现它们共享一个原则——用最小的复杂度换取最大的确定性。Vue 代理配置不当会让前端调试效率减半，缓存选型错误会让服务器承受不必要的压力，SFTP 的权限没设好会带来安全风险，而一个合适的监控脚本则能让你在服务器崩溃前收到预警。

以上这些配置和脚本，我已经整理成了一份可复用的仓库，在 GitHub 上开放。如果你也在搭建类似的技术栈，不妨拿去用，但更重要的是理解背后的取舍逻辑——因为每一套稳定的系统，都是无数次权衡的结果。