这一年来我前前后后折腾了不少部署实验踩过的坑能装满一辆小推车。从最开始拿本地虚拟机练手到后来发现有些场景必须得上真实云服务器再到研究怎么在有限配置下优雅地跑起各种服务这个过程中“哪台云服务器好用”成了我反复思考的问题。这篇文章就是想把这段时间在云服务器选型、基础配置、实战部署上积累的经验记录下来不写空话只讲我实际用过的方案、调过的参数、撞过的墙。如果你是刚开始接触部署、正在纠结怎么选服务器或者已经买了机器但总觉得哪里别扭这篇文章应该能省下你不少摸索的时间。1. 选型前先想清楚部署学习需要一台什么样的云服务器1.1 为什么学习部署首选云服务器而不是本地虚拟机很多朋友一开始都会问我本地有VMware也有Ubuntu为什么还要花钱买云服务器我一开始也是这么想的直到被现实教育了几次。本地虚拟机最大的问题是网络环境太“假”。你在虚拟机里装好Nginx、配好端口本机浏览器访问一下通了似乎一切顺利。但一旦涉及到公网访问、域名解析、安全组规则、异地设备连接这些真实场景本地虚拟机完全模拟不出来。你自己电脑的防火墙、路由器NAT、运营商对大端口和家宽IP的限制都会让一个原本在虚拟机里跑得好好的服务到了公网上就各种诡异。再一个就是资源隔离和持久性。本地虚拟机跑着大模型推理一开就是几个小时风扇狂转不说一旦你合上笔记本盖子服务就断了。而云服务器放在数据中心里7x24小时在线你随时可以通过SSH连上去操作。这种“随时可访问、随时可恢复”的体验对学习部署流程、调试系统服务、观察运行状态来说是质的区别。还有一点很现实云服务器本身就是部署的知识对象。EIP公网IP的概念、安全组和防火墙的关系、系统盘和数据盘的区别、快照和镜像的玩法这些东西不买一台真实云服务器你永远不会真正理解为什么需要有这些设计。我在本地虚拟机里从来没关心过安全组是什么直到买了一台云服务器第一次被人扫描端口、第一次遇到暴力破解登录才明白安全组这层虚拟防火墙到底挡了什么。1.2 配置怎么选CPU、内存、带宽、系统盘的经验值选配置这件事网上说法很多但大多是从销售角度写的什么“入门级”“企业级”听着很玄。我自己折腾下来给学习部署场景一个比较务实的参考CPU和内存学习部署大多数服务2核4G是底线4核8G是舒适区。为什么这么说因为现在很多部署对象已经不是简单的静态网页了。GitLab社区版随便跑起来就要吃2G左右内存Zabbix这种监控系统加上数据库和Web前端4G内存勉强够用。如果你还想在服务器上跑Ollama这类大模型推理哪怕是最小的量化模型4G内存也偏紧8G才能有喘息空间。带宽学习场景下5Mbps的固定带宽基本够用但你要区分“固定带宽”和“按使用流量”两种计费模式。固定带宽的好处是费用可控坏处是下载大模型权重文件、拉取Docker镜像时会非常煎熬几个GB的模型文件在5Mbps带宽下要传一两个小时。按流量计费则相反带宽可以临时拉到很高但流量费要盯着点。我的习惯是需要下载大文件时临时升级带宽或者切按量计费下载完再改回来很多人不知道云厂商控制台里可以这样操作。系统盘默认40G到50G很多人以为够用直到Docker镜像越积越多、模型文件动辄几个GB、数据库binlog不断增长才发现磁盘告急。我的建议是学习机直接上80G以上或者搞清楚你的云厂商怎么加数据盘并挂载。这个钱真的不建议省。再说说系统版本的选择。我踩过一个坑默认选了最新的Ubuntu版本结果某个部署工具的官方文档还没适配各种依赖装不上。现在我的习惯是先到目标软件官网查一下他们推荐的OS版本列表再选对应的云服务器镜像。你可能会觉得这不是云服务器本身的问题但选错镜像导致的折腾时间比选错机型还多。1.3 大厂试用机到底能不能拿来干活热搜里那些“云服务器免费试用”的词我相信不少人都动过心。我自己的经验是大厂的免费试用机拿来学习部署完全够用但有几个前提要想清楚。试用机通常配置不高常见的是1核2G或者2核4G而且试用期一般是1到3个月。如果你只是想跑通部署流程、学会命令操作、理解原理这个配置是够的。但如果你打算长期放着一些服务做实验试用期一到就要面临续费问题。我的建议是把试用期当做一个系统学习周期在试用期内把所有想跑的部署方案都过一遍记录好每一步操作到期后要么付费续上要么换一台新机器重新练一遍——后者其实也是个很好的复习过程。另外要注意试用机的配套限制。有些试用套餐不包含公网IP有些带宽特别低有些只允许你开特定地域的机器。这些都是选型时必须看清楚的。有一次我贪便宜选了个没有公网IP的试用机结果死活连不上后来才发现问题只能重新开机器白白浪费了时间。2. 基础环境配置从裸机到能跑服务的那几步2.1 登录与密钥别再用密码硬刚了新买的云服务器第一步就是登录。大多数人的习惯是用root密码登录但这里有两个隐患第一密码登录容易被暴力破解我见过一台开了密码登录的机器挂公网一天之内就被尝试了几百次登录第二密码本身容易泄露尤其当你喜欢用同一个密码的时候。我的做法是登录后立即配置SSH密钥登录然后关闭密码登录。云厂商控制台一般都有“创建密钥对”的功能一键生成私钥下载然后在控制台绑定到实例上。密钥登录不仅更安全还有个隐藏好处你可以通过私钥配置自动登录脚本批量管理多台服务器。我后来部署集群实验时同时要操作几台机器靠密钥跳来跳去比输入密码高效太多。如果你是跟着教程部署可能还是要用root用户这个OK。但我建议新建一个普通用户日常操作需要root权限时用sudo这样即使某台机器被攻破损失也有限。这个习惯是我的一个朋友在真实生产事故后反复叮嘱我的我现在也一直遵守。2.2 安全组和防火墙默认全通是灾难云服务器的安全组是我觉得新手最容易忽略、却又最重要的配置。很多云厂商默认的安全组规则是“放行全部端口”对新手友好但也给了攻击者机会。我第一次部署Zabbix的时候为了图省事把安全组规则改成了允许所有来源的TCP和UDP流量。结果没过几天服务器上的日志就出现了大量来自陌生IP的扫描记录还有人在尝试用各种弱口令登录我的SSH。从那以后我才认真研究安全组安全组应该只放行你确实需要用到的端口比如SSH的22端口或者改成非标准端口、HTTP的80、HTTPS的443、以及你部署的服务端口来源IP尽量限定在你自己办公网络的公网IP段内。还要注意云厂商的安全组和操作系统自带的防火墙比如firewalld、ufw是两层关系。安全组是云平台层级的虚拟防火墙在实例外部生效系统防火墙是实例内部的规则。我之前想过一个问题安全组已经放行8080端口了为什么外部还是访问不了结果一查是系统防火墙没放行。这两种防火墙要同时配置放行有一个地方漏了服务就是不通。2.3 用宝塔还是裸奔我的选择关于服务器面板国内用得比较多的就是宝塔面板。它对新手确实友好文件管理、数据库管理、Docker管理都可视化了部署WordPress这类网站基本可以鼠标点点点完成。我也用过一段时间必须承认它降低了部署门槛。但如果你要认真学习部署技术我的建议是至少完整地裸奔部署一遍。宝塔帮你做的事情太多了反而掩盖了本质。比如你在宝塔里点一下“安装Nginx”它实际上做了哪些事配置文件在哪里怎么改怎么查看错误日志这些核心知识点会被面板的友好界面全部遮住。等你换一台没有面板的服务器就会发现自己无从下手。我现在的方式是所有学习实验都用纯命令行操作只有偶尔管理一些不常用的工具时才用面板。纯命令行看起来笨拙但它能让你真正理解Linux系统目录结构、进程管理、系统服务这些底层知识。等你熟练之后再回头看面板产品你会发现它们做的事情其实很简单——不过是把命令封装成了可视化按钮。2.4 一次完整的Docker安装与换源记录最近这一两年部署的东西几乎都绕不开Docker。我这里记录一次在Ubuntu云服务器上安装Docker的完整过程并顺手处理镜像源问题因为很多新手直接卡在这一步。首先别急着apt install docker.io那个版本往往偏旧。我习惯用Docker官方提供的安装脚本一条命令就能装好curl -fsSL https://get.docker.com -o get-docker.sh sudo sh get-docker.sh装完之后需要把当前用户加入docker组这样不用每次都sudosudo usermod -aG docker $USER newgrp docker然后配置镜像加速器。这一步在国内环境下几乎是必须的否则拉取镜像时经常超时。你需要去云厂商控制台找到“容器镜像加速器”的地址然后写进Docker的配置里sudo mkdir -p /etc/docker sudo tee /etc/docker/daemon.json -EOF { registry-mirrors: [https://你的加速器地址.mirror.aliyuncs.com] } EOF sudo systemctl daemon-reload sudo systemctl restart docker这里有个小细节配置完镜像加速器之后已经存在的旧镜像不受影响但新拉取时会走加速器。另外docker pull的时候如果遇到manifest unknown之类的报错多半是加速器不支持某个仓库可以临时把加速器配置去掉再试。3. 那些年我在云服务器上跑过的部署实战3.1 用Docker Compose部署全家桶GitLab、Zabbix和蜜罐部署学习这件事光装一个Nginx太没意思了真正让人长进的是那些复杂的、多组件协作的系统。我先后在云服务器上部署过GitLab社区版、Zabbix监控系统还有蜜罐项目每一个都让我对部署有了更深的理解。GitLab社区版算是对新手比较有挑战性的目标。它的部署虽然可以用Docker一条命令拉起来但真要稳定运行、正确配置域名和HTTPS需要处理很多细节。我用的办法是Docker Compose编排一个docker-compose.yml文件里定义GitLab、Redis、PostgreSQL三个服务。这个过程中我对容器的数据卷持久化、容器间的网络通信、环境变量的优先级有了切实的体会。第一次启动GitLab时因为配置了错误的external_url导致网页上生成的仓库地址全是错的排查了半天才发现是这里的问题。Zabbix的部署则让我学会了“分模块理解系统”。Zabbix由Server、Agent、Web前端和数据库四部分组成每一部分都有自己的配置文件和日志。用Docker Compose部署时需要注意各个服务的启动顺序和依赖关系数据库初始化要等PostgreSQL就绪后才能执行。有一次我把数据库连接地址写错了Zabbix Server起来后一直报数据库连接失败Web前端却显示正常这种“一半成功一半失败”的状态排查起来最折磨人。蜜罐部署是我最近才玩的。蜜罐的本质是故意暴露一些服务或端口吸引攻击者来攻击然后记录他们的行为。在一台云服务器上部署蜜罐比本地部署有意思多了因为它接触的是真实公网流量。部署过程中我需要反复调整安全组规则让蜜罐的端口暴露出去同时保证自己真实服务端口不被波及。这个实验让我对网络安全有了更直观的认识——你能在蜜罐日志里看到真实的扫描工具、真实的攻击脚本甚至能分析出机器人在怎么批量探测弱口令。3.2 在2核4G上硬啃DeepSeek和Ollama大模型部署热搜里大模型部署相关的词特别多这也是我最近花时间最多的地方。在云服务器上部署大模型和本地玩完全不是一回事。我试过在一台2核4G的服务器上部署Ollama然后跑DeepSeek的小参数版本。先说结论能跑但体验一般。推理速度很慢一句话要生成半天。后来我在4核8G的机器上跑同样的模型速度才算可接受。这个过程中我学到了两个重要概念显存和内存的关系以及量化对模型体积的影响。大模型部署不是把文件放上去就能用的它需要把模型加载到内存里做推理。Ollama会在模型启动时做量化加载模型文件越大启动越慢。我一开始以为下载模型文件到本地就万事大吉结果发现每次重启服务都要重新加载模型几GB的加载时间加上内存不够时的Swap交换直接把服务器拖死。后来我学乖了选模型时专门找量化版本比如Q4_K_M这种体积缩小了不少精度损失在可接受范围内。如果你也想在云服务器上玩大模型我给你几个实在的建议内存低于8G的话别碰7B以上的模型跑起来也是受罪别用系统盘存模型文件有条件就挂数据盘因为模型反复下载、删除会占用大量空间Ollama的默认模型存储路径在/usr/share/ollama/.ollama/models可以通过环境变量OLLAMA_MODELS改到数据盘我就是这么干的不要同时跑多个模型Ollama默认会把不再使用的模型从内存中卸载但如果你的内存不够它可能会频繁加载卸载反而更慢DeepSeek本地部署这块我用的方案是ollama跑模型然后通过OpenAI兼容API接入到各种应用里。这里有个关键操作Ollama默认只监听127.0.0.1你要让它监听0.0.0.0才能让另一台机器上的应用通过局域网访问它# 设置环境变量 sudo systemctl edit ollama # 添加以下内容 [Service] EnvironmentOLLAMA_HOST0.0.0.0 EnvironmentOLLAMA_MODELS/data/ollama-models设置完之后重启Ollama然后就可以在另一台机器上用OpenAI SDK的base_url指向这台服务器的IP和11434端口了。3.3 Dify、Langfuse这类AI应用编排工具怎么落地除了模型本身现在更火的是AI应用编排平台。Dify、Langfuse这类项目在热搜里频繁出现说明很多人已经在研究怎么把大模型真正落地到业务里。Dify这个项目我部署过两遍第一遍踩了不少坑。它的官方推荐部署方式是Docker Compose拉取一整套服务包括API服务、Worker、Web前端、PostgreSQL、Redis、Weaviate等十几个容器一起起来。这个规模对服务器的要求并不低我第一次在2核4G上部署启动过程内存直接爆掉后来换了4核8G才顺利跑起来。部署Dify这类项目时我最深的体会是不要盲目用最新版本跟着官方文档的版本走。他们有时候会在release说明里写清楚某个版本依赖什么环境先看清楚再动手。另外Docker Compose的.env配置文件很关键很多配置项都会在启动时被读取改了配置后要记得重新执行docker compose up -d让配置生效而不是只重启某一个容器。Langfuse的部署则相对简单一点它是专门做大模型应用的可观测性和日志记录的。我用它来记录自己开发的AI Agent的每一次调用包括输入、输出、token消耗和延迟。部署Langfuse也需要Docker Compose整体架构比Dify轻量2核4G可以跑。但要注意它的数据库迁移机制升级版本时数据库会自动做migration如果服务器磁盘空间不够migration过程中很容易失败所以经常检查磁盘余量。3.4 监控和安全部署部署不只是把服务拉起来说到部署很多人觉得服务起来了就算完事但我觉得真正的部署是包括“运行观察”在内的。这也是为什么我会专门在一台云服务器上部署Zabbix和Suricata这类工具。Zabbix部署起来之后你要配置监控项、触发器、告警媒介。我监控了CPU使用率、内存使用率、磁盘空间、系统负载等基础指标也监控了自己部署的业务服务的端口存活状态。配置告警时要注意阈值设定阈值设得太低容易频繁误报设得太高又失去意义。我一开始把CPU告警阈值设在80%结果发现编译或者拉镜像时经常突破后来改成90%并且加了持续时间条件持续5分钟才告警噪音少了很多。Suricata是入侵检测系统我拿它来监控服务器网卡上的流量。部署流程不复杂关键是规则配置和日志分析。Suricata默认的规则可能让你面对海量告警因为公网上稀奇古怪的流量太多了。我的做法是先打开suricata.yaml里的af-packet模式让它监听主网卡然后导入EVE JSON格式的日志到Elasticsearch做可视化分析。这个复杂度比较高但收获也很大你会看到真实的网络攻击模式而不是教科书里那几句抽象描述。这里提醒一句不要把监控和安全部署当摆设。部署完Zabbix和Suricata之后你最好真的去制造一些异常情况比如故意填满磁盘、故意开放一个不用的端口看看监控能不能及时告警、IDS能不能捕获到扫描流量。只有验证过你的监控系统是有效的它才有意义。4. 我踩过的坑和排查思路速查4.1 端口明明放行了还是连不上这是我被问过最多的问题也是我早期最头疼的问题。部署完一个服务在服务器本机用curl访问正常但用自己的电脑浏览器访问就是打不开。排查思路按顺序来先确认服务监听的地址。用ss -tlnp查看如果服务的监听地址是127.0.0.1那它只允许本机访问外部当然连不上。这种情况需要改服务配置让它监听0.0.0.0或者具体的网卡IP。再确认云平台安全组有没有放行对应端口。在云厂商控制台看安全组规则入方向是否允许来自你的IP或全部IP访问该端口。接着确认操作系统防火墙。Ubuntu的ufw status、CentOS的firewalld-cmd --list-all看看有没有放行。有时候你在安全组里放行了但系统防火墙没放行一样不通。最后测试网络链路。在自己的电脑上telnet一下服务器IP和端口如果timeout基本就是上面三层中某一层拦截了。我遇到过一个比较隐蔽的情况服务本身监听正常安全组和防火墙都放行了但就是连不上。最后发现是云服务器的“外网防火墙”或者“DDoS防护”里有额外的端口封禁策略一般在控制台的安全设置里能找到。这种问题靠文档很难发现只能一点点排查。4.2 磁盘满了日志在疯狂占用空间部署完几个服务之后磁盘空间会以你想象不到的速度消耗。我最惨的一次是部署完Dify后没过几天系统盘直接被占满数据库服务直接挂掉。查下来罪魁祸首是容器日志——Docker默认会把所有容器的stdout输出记录到/var/lib/docker/containers/下的json文件里这个文件默认不限制大小一个服务如果疯狂打日志几天就能吃掉几十个GB。解决方法是给Docker配置日志轮转。在/etc/docker/daemon.json里加上{ log-driver: json-file, log-opts: { max-size: 10m, max-file: 3 } }配置完之后重启Docker新创建的容器就会按照这个策略限制日志大小。注意已经存在的容器不会自动生效你需要重新创建容器或者手动清一下现有的日志文件。这是一个经验教训我后来凡是部署新容器都会先确认日志轮转已经开启。除了容器日志还有系统自身的日志比如/var/log/syslog、/var/log/auth.log以及包管理器的缓存。隔一段时间跑一次journalctl --vacuum-size100M清清系统日志再用apt autoclean清理缓存能释放不少空间。日常部署的时候养成好习惯——每部署一个东西就用du -sh看看哪个目录占用空间大心中有数不会等到磁盘满了才被动处理。4.3 内存不够时Swap到底救不救得了场在低配云服务器上跑多个服务内存告急是家常便饭。我一开始死活不想开Swap因为网上说Swap会让性能变得很烂。但实际用了之后我的看法是Swap不能救命但能保命。当你的服务遇到内存峰值时如果没有Swap进程可能直接被OOM Killer杀掉。你辛苦部署的服务莫名其妙就没了排查半天发现是内存不够被系统杀了这种感觉非常糟。开了Swap之后进程不会立刻被杀而是会变慢——很多时候服务慢一点还能接受挂掉就完全不能用了。我的建议是内存小于4G的机器设置2G到4G的Swap内存大于8G的机器Swap可以小一点比如2G。设置方法很简单sudo fallocate -l 4G /swapfile sudo chmod 600 /swapfile sudo mkswap /swapfile sudo swapon /swapfile然后写进/etc/fstab保证开机自动挂载。这里有个坑有些云厂商的默认内核参数里swappinessSwap使用倾向度可能被设得比较激进你可以检查一下/proc/sys/vm/swappiness如果数值大于60建议改成10到30让系统优先使用物理内存避免不必要的磁盘交换。4.4 部署完跑不起来学会看日志和systemd状态很多新手部署时遇到服务启动失败就懵了只知道对着教程反复看哪里不一样。我要说的是服务起不来不可怕可怕的是你不会看日志。以systemd管理的服务为例只要记住这几条命令systemctl status 服务名 # 查看服务状态和最近日志 journalctl -u 服务名 -n 100 # 查看最近100行日志 journalctl -u 服务名 -f # 实时跟踪日志如果是Docker容器docker ps -a # 看容器是否在运行以及退出码 docker logs 容器名 # 看容器日志 docker logs -f 容器名 # 实时跟踪日志是最诚实的它会直接告诉你错误原因。比如端口被占用、配置文件格式错误、数据库连接超时、权限不足全部会写在日志里。我见过有人花了一个小时反复重装服务最后发现只是配置文件里多了一个空格。多看一眼日志少折腾一晚上这话放在部署领域绝对是真理。如果你不知道日志在哪里一般服务的文档里都会写。Nginx在/var/log/nginx/Zabbix Server在/var/log/zabbix/Dify在容器日志里。有些服务会把日志放在/var/log/消息里用journalctl查不到这时候你就要去翻/var/log目录下的具体文件。5. 关于“好用”的重新定义回到标题里说的“好用的云服务器”我现在对这个词的理解和一年前完全不同了。以前我觉得好用就是配置高、价格低、界面漂亮现在我觉得好用是文档清晰、社区活跃、控制台操作顺手、安全组和镜像功能不反人类、故障排查时不绕弯子。阿里云、腾讯云、华为云这些大厂的机器我都用过说实话在基础性能上并没有天壤之别真正拉开差距的是你熟悉程度——一台你用顺手、知道去哪里看监控、知道怎么改安全组、知道遇到问题去哪个文档里找答案的服务器就是对你来说最好用的服务器。另外我特别想说的是好用的云服务器其实是“逼”出来的。你配置它、部署它、折腾它、修复它这个过程让一台原本普普通通的机器变成了了解你需求和习惯的伙伴。每踩过一个坑你就对这台机器多一分理解每跑通一个服务你就对部署这件事多一分底气。所以别纠结于哪台机器绝对最好选一台经济范围内配置合适的然后好好折腾它它自然会变成你好用的那一台。最后再分享一个小技巧每次部署完一个重要服务把操作步骤、配置文件、遇到的问题和解决办法都记录下来存成自己的笔记。我用了很长一段时间后回头看这些笔记发现自己很多“想当然”的操作其实都在笔记里被纠正过了这些笔记比任何官方文档都更贴合我的实际情况。如果你从今天开始部署第一台云服务器希望这篇记录能帮你少走一些弯路也祝你的部署过程多一些顺利、少一些通宵。 
长河君 · 2026/9/26 13:48:48 · 阅读 1.2k 云服务器部署实战：选型、配置与踩坑全记录
这一年来我前前后后折腾了不少部署实验踩过的坑能装满一辆小推车。从最开始拿本地虚拟机练手到后来发现有些场景必须得上真实云服务器再到研究怎么在有限配置下优雅地跑起各种服务这个过程中“哪台云服务器好用”成了我反复思考的问题。这篇文章就是想把这段时间在云服务器选型、基础配置、实战部署上积累的经验记录下来不写空话只讲我实际用过的方案、调过的参数、撞过的墙。如果你是刚开始接触部署、正在纠结怎么选服务器或者已经买了机器但总觉得哪里别扭这篇文章应该能省下你不少摸索的时间。1. 选型前先想清楚部署学习需要一台什么样的云服务器1.1 为什么学习部署首选云服务器而不是本地虚拟机很多朋友一开始都会问我本地有VMware也有Ubuntu为什么还要花钱买云服务器我一开始也是这么想的直到被现实教育了几次。本地虚拟机最大的问题是网络环境太“假”。你在虚拟机里装好Nginx、配好端口本机浏览器访问一下通了似乎一切顺利。但一旦涉及到公网访问、域名解析、安全组规则、异地设备连接这些真实场景本地虚拟机完全模拟不出来。你自己电脑的防火墙、路由器NAT、运营商对大端口和家宽IP的限制都会让一个原本在虚拟机里跑得好好的服务到了公网上就各种诡异。再一个就是资源隔离和持久性。本地虚拟机跑着大模型推理一开就是几个小时风扇狂转不说一旦你合上笔记本盖子服务就断了。而云服务器放在数据中心里7x24小时在线你随时可以通过SSH连上去操作。这种“随时可访问、随时可恢复”的体验对学习部署流程、调试系统服务、观察运行状态来说是质的区别。还有一点很现实云服务器本身就是部署的知识对象。EIP公网IP的概念、安全组和防火墙的关系、系统盘和数据盘的区别、快照和镜像的玩法这些东西不买一台真实云服务器你永远不会真正理解为什么需要有这些设计。我在本地虚拟机里从来没关心过安全组是什么直到买了一台云服务器第一次被人扫描端口、第一次遇到暴力破解登录才明白安全组这层虚拟防火墙到底挡了什么。1.2 配置怎么选CPU、内存、带宽、系统盘的经验值选配置这件事网上说法很多但大多是从销售角度写的什么“入门级”“企业级”听着很玄。我自己折腾下来给学习部署场景一个比较务实的参考CPU和内存学习部署大多数服务2核4G是底线4核8G是舒适区。为什么这么说因为现在很多部署对象已经不是简单的静态网页了。GitLab社区版随便跑起来就要吃2G左右内存Zabbix这种监控系统加上数据库和Web前端4G内存勉强够用。如果你还想在服务器上跑Ollama这类大模型推理哪怕是最小的量化模型4G内存也偏紧8G才能有喘息空间。带宽学习场景下5Mbps的固定带宽基本够用但你要区分“固定带宽”和“按使用流量”两种计费模式。固定带宽的好处是费用可控坏处是下载大模型权重文件、拉取Docker镜像时会非常煎熬几个GB的模型文件在5Mbps带宽下要传一两个小时。按流量计费则相反带宽可以临时拉到很高但流量费要盯着点。我的习惯是需要下载大文件时临时升级带宽或者切按量计费下载完再改回来很多人不知道云厂商控制台里可以这样操作。系统盘默认40G到50G很多人以为够用直到Docker镜像越积越多、模型文件动辄几个GB、数据库binlog不断增长才发现磁盘告急。我的建议是学习机直接上80G以上或者搞清楚你的云厂商怎么加数据盘并挂载。这个钱真的不建议省。再说说系统版本的选择。我踩过一个坑默认选了最新的Ubuntu版本结果某个部署工具的官方文档还没适配各种依赖装不上。现在我的习惯是先到目标软件官网查一下他们推荐的OS版本列表再选对应的云服务器镜像。你可能会觉得这不是云服务器本身的问题但选错镜像导致的折腾时间比选错机型还多。1.3 大厂试用机到底能不能拿来干活热搜里那些“云服务器免费试用”的词我相信不少人都动过心。我自己的经验是大厂的免费试用机拿来学习部署完全够用但有几个前提要想清楚。试用机通常配置不高常见的是1核2G或者2核4G而且试用期一般是1到3个月。如果你只是想跑通部署流程、学会命令操作、理解原理这个配置是够的。但如果你打算长期放着一些服务做实验试用期一到就要面临续费问题。我的建议是把试用期当做一个系统学习周期在试用期内把所有想跑的部署方案都过一遍记录好每一步操作到期后要么付费续上要么换一台新机器重新练一遍——后者其实也是个很好的复习过程。另外要注意试用机的配套限制。有些试用套餐不包含公网IP有些带宽特别低有些只允许你开特定地域的机器。这些都是选型时必须看清楚的。有一次我贪便宜选了个没有公网IP的试用机结果死活连不上后来才发现问题只能重新开机器白白浪费了时间。2. 基础环境配置从裸机到能跑服务的那几步2.1 登录与密钥别再用密码硬刚了新买的云服务器第一步就是登录。大多数人的习惯是用root密码登录但这里有两个隐患第一密码登录容易被暴力破解我见过一台开了密码登录的机器挂公网一天之内就被尝试了几百次登录第二密码本身容易泄露尤其当你喜欢用同一个密码的时候。我的做法是登录后立即配置SSH密钥登录然后关闭密码登录。云厂商控制台一般都有“创建密钥对”的功能一键生成私钥下载然后在控制台绑定到实例上。密钥登录不仅更安全还有个隐藏好处你可以通过私钥配置自动登录脚本批量管理多台服务器。我后来部署集群实验时同时要操作几台机器靠密钥跳来跳去比输入密码高效太多。如果你是跟着教程部署可能还是要用root用户这个OK。但我建议新建一个普通用户日常操作需要root权限时用sudo这样即使某台机器被攻破损失也有限。这个习惯是我的一个朋友在真实生产事故后反复叮嘱我的我现在也一直遵守。2.2 安全组和防火墙默认全通是灾难云服务器的安全组是我觉得新手最容易忽略、却又最重要的配置。很多云厂商默认的安全组规则是“放行全部端口”对新手友好但也给了攻击者机会。我第一次部署Zabbix的时候为了图省事把安全组规则改成了允许所有来源的TCP和UDP流量。结果没过几天服务器上的日志就出现了大量来自陌生IP的扫描记录还有人在尝试用各种弱口令登录我的SSH。从那以后我才认真研究安全组安全组应该只放行你确实需要用到的端口比如SSH的22端口或者改成非标准端口、HTTP的80、HTTPS的443、以及你部署的服务端口来源IP尽量限定在你自己办公网络的公网IP段内。还要注意云厂商的安全组和操作系统自带的防火墙比如firewalld、ufw是两层关系。安全组是云平台层级的虚拟防火墙在实例外部生效系统防火墙是实例内部的规则。我之前想过一个问题安全组已经放行8080端口了为什么外部还是访问不了结果一查是系统防火墙没放行。这两种防火墙要同时配置放行有一个地方漏了服务就是不通。2.3 用宝塔还是裸奔我的选择关于服务器面板国内用得比较多的就是宝塔面板。它对新手确实友好文件管理、数据库管理、Docker管理都可视化了部署WordPress这类网站基本可以鼠标点点点完成。我也用过一段时间必须承认它降低了部署门槛。但如果你要认真学习部署技术我的建议是至少完整地裸奔部署一遍。宝塔帮你做的事情太多了反而掩盖了本质。比如你在宝塔里点一下“安装Nginx”它实际上做了哪些事配置文件在哪里怎么改怎么查看错误日志这些核心知识点会被面板的友好界面全部遮住。等你换一台没有面板的服务器就会发现自己无从下手。我现在的方式是所有学习实验都用纯命令行操作只有偶尔管理一些不常用的工具时才用面板。纯命令行看起来笨拙但它能让你真正理解Linux系统目录结构、进程管理、系统服务这些底层知识。等你熟练之后再回头看面板产品你会发现它们做的事情其实很简单——不过是把命令封装成了可视化按钮。2.4 一次完整的Docker安装与换源记录最近这一两年部署的东西几乎都绕不开Docker。我这里记录一次在Ubuntu云服务器上安装Docker的完整过程并顺手处理镜像源问题因为很多新手直接卡在这一步。首先别急着apt install docker.io那个版本往往偏旧。我习惯用Docker官方提供的安装脚本一条命令就能装好curl -fsSL https://get.docker.com -o get-docker.sh sudo sh get-docker.sh装完之后需要把当前用户加入docker组这样不用每次都sudosudo usermod -aG docker $USER newgrp docker然后配置镜像加速器。这一步在国内环境下几乎是必须的否则拉取镜像时经常超时。你需要去云厂商控制台找到“容器镜像加速器”的地址然后写进Docker的配置里sudo mkdir -p /etc/docker sudo tee /etc/docker/daemon.json -EOF { registry-mirrors: [https://你的加速器地址.mirror.aliyuncs.com] } EOF sudo systemctl daemon-reload sudo systemctl restart docker这里有个小细节配置完镜像加速器之后已经存在的旧镜像不受影响但新拉取时会走加速器。另外docker pull的时候如果遇到manifest unknown之类的报错多半是加速器不支持某个仓库可以临时把加速器配置去掉再试。3. 那些年我在云服务器上跑过的部署实战3.1 用Docker Compose部署全家桶GitLab、Zabbix和蜜罐部署学习这件事光装一个Nginx太没意思了真正让人长进的是那些复杂的、多组件协作的系统。我先后在云服务器上部署过GitLab社区版、Zabbix监控系统还有蜜罐项目每一个都让我对部署有了更深的理解。GitLab社区版算是对新手比较有挑战性的目标。它的部署虽然可以用Docker一条命令拉起来但真要稳定运行、正确配置域名和HTTPS需要处理很多细节。我用的办法是Docker Compose编排一个docker-compose.yml文件里定义GitLab、Redis、PostgreSQL三个服务。这个过程中我对容器的数据卷持久化、容器间的网络通信、环境变量的优先级有了切实的体会。第一次启动GitLab时因为配置了错误的external_url导致网页上生成的仓库地址全是错的排查了半天才发现是这里的问题。Zabbix的部署则让我学会了“分模块理解系统”。Zabbix由Server、Agent、Web前端和数据库四部分组成每一部分都有自己的配置文件和日志。用Docker Compose部署时需要注意各个服务的启动顺序和依赖关系数据库初始化要等PostgreSQL就绪后才能执行。有一次我把数据库连接地址写错了Zabbix Server起来后一直报数据库连接失败Web前端却显示正常这种“一半成功一半失败”的状态排查起来最折磨人。蜜罐部署是我最近才玩的。蜜罐的本质是故意暴露一些服务或端口吸引攻击者来攻击然后记录他们的行为。在一台云服务器上部署蜜罐比本地部署有意思多了因为它接触的是真实公网流量。部署过程中我需要反复调整安全组规则让蜜罐的端口暴露出去同时保证自己真实服务端口不被波及。这个实验让我对网络安全有了更直观的认识——你能在蜜罐日志里看到真实的扫描工具、真实的攻击脚本甚至能分析出机器人在怎么批量探测弱口令。3.2 在2核4G上硬啃DeepSeek和Ollama大模型部署热搜里大模型部署相关的词特别多这也是我最近花时间最多的地方。在云服务器上部署大模型和本地玩完全不是一回事。我试过在一台2核4G的服务器上部署Ollama然后跑DeepSeek的小参数版本。先说结论能跑但体验一般。推理速度很慢一句话要生成半天。后来我在4核8G的机器上跑同样的模型速度才算可接受。这个过程中我学到了两个重要概念显存和内存的关系以及量化对模型体积的影响。大模型部署不是把文件放上去就能用的它需要把模型加载到内存里做推理。Ollama会在模型启动时做量化加载模型文件越大启动越慢。我一开始以为下载模型文件到本地就万事大吉结果发现每次重启服务都要重新加载模型几GB的加载时间加上内存不够时的Swap交换直接把服务器拖死。后来我学乖了选模型时专门找量化版本比如Q4_K_M这种体积缩小了不少精度损失在可接受范围内。如果你也想在云服务器上玩大模型我给你几个实在的建议内存低于8G的话别碰7B以上的模型跑起来也是受罪别用系统盘存模型文件有条件就挂数据盘因为模型反复下载、删除会占用大量空间Ollama的默认模型存储路径在/usr/share/ollama/.ollama/models可以通过环境变量OLLAMA_MODELS改到数据盘我就是这么干的不要同时跑多个模型Ollama默认会把不再使用的模型从内存中卸载但如果你的内存不够它可能会频繁加载卸载反而更慢DeepSeek本地部署这块我用的方案是ollama跑模型然后通过OpenAI兼容API接入到各种应用里。这里有个关键操作Ollama默认只监听127.0.0.1你要让它监听0.0.0.0才能让另一台机器上的应用通过局域网访问它# 设置环境变量 sudo systemctl edit ollama # 添加以下内容 [Service] EnvironmentOLLAMA_HOST0.0.0.0 EnvironmentOLLAMA_MODELS/data/ollama-models设置完之后重启Ollama然后就可以在另一台机器上用OpenAI SDK的base_url指向这台服务器的IP和11434端口了。3.3 Dify、Langfuse这类AI应用编排工具怎么落地除了模型本身现在更火的是AI应用编排平台。Dify、Langfuse这类项目在热搜里频繁出现说明很多人已经在研究怎么把大模型真正落地到业务里。Dify这个项目我部署过两遍第一遍踩了不少坑。它的官方推荐部署方式是Docker Compose拉取一整套服务包括API服务、Worker、Web前端、PostgreSQL、Redis、Weaviate等十几个容器一起起来。这个规模对服务器的要求并不低我第一次在2核4G上部署启动过程内存直接爆掉后来换了4核8G才顺利跑起来。部署Dify这类项目时我最深的体会是不要盲目用最新版本跟着官方文档的版本走。他们有时候会在release说明里写清楚某个版本依赖什么环境先看清楚再动手。另外Docker Compose的.env配置文件很关键很多配置项都会在启动时被读取改了配置后要记得重新执行docker compose up -d让配置生效而不是只重启某一个容器。Langfuse的部署则相对简单一点它是专门做大模型应用的可观测性和日志记录的。我用它来记录自己开发的AI Agent的每一次调用包括输入、输出、token消耗和延迟。部署Langfuse也需要Docker Compose整体架构比Dify轻量2核4G可以跑。但要注意它的数据库迁移机制升级版本时数据库会自动做migration如果服务器磁盘空间不够migration过程中很容易失败所以经常检查磁盘余量。3.4 监控和安全部署部署不只是把服务拉起来说到部署很多人觉得服务起来了就算完事但我觉得真正的部署是包括“运行观察”在内的。这也是为什么我会专门在一台云服务器上部署Zabbix和Suricata这类工具。Zabbix部署起来之后你要配置监控项、触发器、告警媒介。我监控了CPU使用率、内存使用率、磁盘空间、系统负载等基础指标也监控了自己部署的业务服务的端口存活状态。配置告警时要注意阈值设定阈值设得太低容易频繁误报设得太高又失去意义。我一开始把CPU告警阈值设在80%结果发现编译或者拉镜像时经常突破后来改成90%并且加了持续时间条件持续5分钟才告警噪音少了很多。Suricata是入侵检测系统我拿它来监控服务器网卡上的流量。部署流程不复杂关键是规则配置和日志分析。Suricata默认的规则可能让你面对海量告警因为公网上稀奇古怪的流量太多了。我的做法是先打开suricata.yaml里的af-packet模式让它监听主网卡然后导入EVE JSON格式的日志到Elasticsearch做可视化分析。这个复杂度比较高但收获也很大你会看到真实的网络攻击模式而不是教科书里那几句抽象描述。这里提醒一句不要把监控和安全部署当摆设。部署完Zabbix和Suricata之后你最好真的去制造一些异常情况比如故意填满磁盘、故意开放一个不用的端口看看监控能不能及时告警、IDS能不能捕获到扫描流量。只有验证过你的监控系统是有效的它才有意义。4. 我踩过的坑和排查思路速查4.1 端口明明放行了还是连不上这是我被问过最多的问题也是我早期最头疼的问题。部署完一个服务在服务器本机用curl访问正常但用自己的电脑浏览器访问就是打不开。排查思路按顺序来先确认服务监听的地址。用ss -tlnp查看如果服务的监听地址是127.0.0.1那它只允许本机访问外部当然连不上。这种情况需要改服务配置让它监听0.0.0.0或者具体的网卡IP。再确认云平台安全组有没有放行对应端口。在云厂商控制台看安全组规则入方向是否允许来自你的IP或全部IP访问该端口。接着确认操作系统防火墙。Ubuntu的ufw status、CentOS的firewalld-cmd --list-all看看有没有放行。有时候你在安全组里放行了但系统防火墙没放行一样不通。最后测试网络链路。在自己的电脑上telnet一下服务器IP和端口如果timeout基本就是上面三层中某一层拦截了。我遇到过一个比较隐蔽的情况服务本身监听正常安全组和防火墙都放行了但就是连不上。最后发现是云服务器的“外网防火墙”或者“DDoS防护”里有额外的端口封禁策略一般在控制台的安全设置里能找到。这种问题靠文档很难发现只能一点点排查。4.2 磁盘满了日志在疯狂占用空间部署完几个服务之后磁盘空间会以你想象不到的速度消耗。我最惨的一次是部署完Dify后没过几天系统盘直接被占满数据库服务直接挂掉。查下来罪魁祸首是容器日志——Docker默认会把所有容器的stdout输出记录到/var/lib/docker/containers/下的json文件里这个文件默认不限制大小一个服务如果疯狂打日志几天就能吃掉几十个GB。解决方法是给Docker配置日志轮转。在/etc/docker/daemon.json里加上{ log-driver: json-file, log-opts: { max-size: 10m, max-file: 3 } }配置完之后重启Docker新创建的容器就会按照这个策略限制日志大小。注意已经存在的容器不会自动生效你需要重新创建容器或者手动清一下现有的日志文件。这是一个经验教训我后来凡是部署新容器都会先确认日志轮转已经开启。除了容器日志还有系统自身的日志比如/var/log/syslog、/var/log/auth.log以及包管理器的缓存。隔一段时间跑一次journalctl --vacuum-size100M清清系统日志再用apt autoclean清理缓存能释放不少空间。日常部署的时候养成好习惯——每部署一个东西就用du -sh看看哪个目录占用空间大心中有数不会等到磁盘满了才被动处理。4.3 内存不够时Swap到底救不救得了场在低配云服务器上跑多个服务内存告急是家常便饭。我一开始死活不想开Swap因为网上说Swap会让性能变得很烂。但实际用了之后我的看法是Swap不能救命但能保命。当你的服务遇到内存峰值时如果没有Swap进程可能直接被OOM Killer杀掉。你辛苦部署的服务莫名其妙就没了排查半天发现是内存不够被系统杀了这种感觉非常糟。开了Swap之后进程不会立刻被杀而是会变慢——很多时候服务慢一点还能接受挂掉就完全不能用了。我的建议是内存小于4G的机器设置2G到4G的Swap内存大于8G的机器Swap可以小一点比如2G。设置方法很简单sudo fallocate -l 4G /swapfile sudo chmod 600 /swapfile sudo mkswap /swapfile sudo swapon /swapfile然后写进/etc/fstab保证开机自动挂载。这里有个坑有些云厂商的默认内核参数里swappinessSwap使用倾向度可能被设得比较激进你可以检查一下/proc/sys/vm/swappiness如果数值大于60建议改成10到30让系统优先使用物理内存避免不必要的磁盘交换。4.4 部署完跑不起来学会看日志和systemd状态很多新手部署时遇到服务启动失败就懵了只知道对着教程反复看哪里不一样。我要说的是服务起不来不可怕可怕的是你不会看日志。以systemd管理的服务为例只要记住这几条命令systemctl status 服务名 # 查看服务状态和最近日志 journalctl -u 服务名 -n 100 # 查看最近100行日志 journalctl -u 服务名 -f # 实时跟踪日志如果是Docker容器docker ps -a # 看容器是否在运行以及退出码 docker logs 容器名 # 看容器日志 docker logs -f 容器名 # 实时跟踪日志是最诚实的它会直接告诉你错误原因。比如端口被占用、配置文件格式错误、数据库连接超时、权限不足全部会写在日志里。我见过有人花了一个小时反复重装服务最后发现只是配置文件里多了一个空格。多看一眼日志少折腾一晚上这话放在部署领域绝对是真理。如果你不知道日志在哪里一般服务的文档里都会写。Nginx在/var/log/nginx/Zabbix Server在/var/log/zabbix/Dify在容器日志里。有些服务会把日志放在/var/log/消息里用journalctl查不到这时候你就要去翻/var/log目录下的具体文件。5. 关于“好用”的重新定义回到标题里说的“好用的云服务器”我现在对这个词的理解和一年前完全不同了。以前我觉得好用就是配置高、价格低、界面漂亮现在我觉得好用是文档清晰、社区活跃、控制台操作顺手、安全组和镜像功能不反人类、故障排查时不绕弯子。阿里云、腾讯云、华为云这些大厂的机器我都用过说实话在基础性能上并没有天壤之别真正拉开差距的是你熟悉程度——一台你用顺手、知道去哪里看监控、知道怎么改安全组、知道遇到问题去哪个文档里找答案的服务器就是对你来说最好用的服务器。另外我特别想说的是好用的云服务器其实是“逼”出来的。你配置它、部署它、折腾它、修复它这个过程让一台原本普普通通的机器变成了了解你需求和习惯的伙伴。每踩过一个坑你就对这台机器多一分理解每跑通一个服务你就对部署这件事多一分底气。所以别纠结于哪台机器绝对最好选一台经济范围内配置合适的然后好好折腾它它自然会变成你好用的那一台。最后再分享一个小技巧每次部署完一个重要服务把操作步骤、配置文件、遇到的问题和解决办法都记录下来存成自己的笔记。我用了很长一段时间后回头看这些笔记发现自己很多“想当然”的操作其实都在笔记里被纠正过了这些笔记比任何官方文档都更贴合我的实际情况。如果你从今天开始部署第一台云服务器希望这篇记录能帮你少走一些弯路也祝你的部署过程多一些顺利、少一些通宵。