我手头常年躺着一堆“上不了台面”的小项目：GitHub Pages上写了半截的博客、一台用来跑自动化脚本的轻量云服务器、一个想发给客户看效果的后台Demo。这类东西有个共同问题：需要一个域名，但又不想为它每年花几十上百。
免费申请永久域名这件事，我前前后后把能踩的路都走了一遍，最后稳定跑起来、一直用到现在没出过问题的，是eu.org。这篇就把我从注册账号到实际解析绑定的完整过程写清楚，包括申请时容易踩的坑、审核等待的正确姿势，以及拿到域名后怎么快速把它用到博客、服务器和API调试场景里。适合所有想白嫖一个好域名的个人开发者、学生和折腾党。
1. 为什么“永久免费域名”真的存在，以及我为什么选了eu.org
1.1 域名只有“租用期”，“永久”到底是什么含义
严格讲，互联网域名体系（ICANN）里不存在“买断”这回事。你注册一个.com，本质是从注册商那里租用一年，到期续费，最长一次可以续到10年。所以任何号称“永久域名”的服务，意思都不是“这个域名永远归你”，而是“只要你遵守规则，不需要每年续费，域名不会因为不交钱被回收”。
eu.org提供的正是这种模式。它是一个1996年就开始运营的老牌免费域名服务，由欧洲的非营利组织维护，对外提供yourname.eu.org这种二级域名，注册免费，没有续费要求。听起来有点“非主流”，但它在免费域名圈里已经活了二十多年，稳定程度甚至超过了不少商业化服务。
我自己的使用时间不算特别长，但几年下来，域名始终Active，官网没发过任何付费通知，也没有强制迁移。对于一个免费服务来说，这种“安静”本身就是最大的安全感。
1.2 免费域名圈里倒掉的太多了，为什么eu.org能活
免费域名这个赛道，这些年倒掉的产品一抓一大把。很多服务早期靠免费引流，等用户量上来后要么转收费、要么被收购后关闭，最后用户手里的域名直接作废。还有一类是没扛住滥用，被垃圾注册塞满，整体信誉崩掉。
eu.org能活下来的原因其实很朴素：非营利背景决定了它没有“变现压力”；组织本身和欧洲学术网络有渊源，运营纯粹是基础设施性质；再加上它只做二级域分发这一件事，不碰复杂的商业化功能。没有商业模型的扭曲，反而让它成了那个活得最久的。
在圈子里，想免费申请一个能长期用的域名，第一反应基本都是eu.org。Freenom那类服务目前基本没法正常注册了，其他小平台又不太敢用，eu.org几乎是硕果仅存的正规老牌选择。
1.3 什么样的项目适合用它，什么样的不适合
免费域名不等于万能，用之前先对照一下自己的场景。
适合的包括：个人博客和知识库、GitHub Pages或Vercel上的静态站点、开发测试环境、API网关跳转、内网穿透入口、临时发给客户看的演示页。这些场景看重“有个正经域名可用”，对品牌和信誉要求不高，eu.org完全够用。
不适合的我也直接说：商业品牌、企业官方网站、主邮件服务器、需要做ICP备案的小程序或域名（如果你的服务器在境内，免费域名基本不具备备案条件）、以及那种“未来可能要融资上市”的项目。免费域名毕竟在他人控制之下，规则变更、项目关停都不是我们能决定的，关键业务别把它当根基。
2. 申请前想清楚三件事，比急着注册重要得多
2.1 给你的子域取一个“将来不后悔”的名字
eu.org申请的格式是：你输入一个前缀，变成你的前缀.eu.org。比如我输入myblog，最终得到myblog.eu.org。
命名时注意几点：
- 只用字母、数字、连字符，连字符不要放开头和结尾；
- 尽量短，方便口头告诉别人；
- 避免和知名品牌撞车，比如用nike.eu.org这类明显有侵权风险的名字，基本不会过审；
- 不要用那种看起来像机器随机生成的字符串，显得很可疑；
- 如果你有多个项目，可以申请多个不同前缀的域名，或者申请一个主域名后，用DNS里加子域的方式区分项目，比如blog.myblog.eu.org、api.myblog.eu.org。
如果你打算长期用，我建议前缀和你的个人品牌或常用ID保持一致，这样以后做作品集、简历也自然。
2.2 提前决定DNS托管方式：eu.org自带还是Cloudflare
这是很多人申请时忽略的一步，但直接影响后续使用体验。
方案A：直接用eu.org自带的DNS管理面板。申请时不用填额外信息，通过后在eu.org后台加A记录、CNAME记录就行。优点是省事，缺点是没有CDN，也没有自动证书管理。
方案B：把DNS托管到Cloudflare。先在Cloudflare添加站点，拿到两个NS服务器地址，申请eu.org时把这俩NS填进去。审核通过后，Cloudflare就能帮你解析域名，还能白嫖免费CDN、免费SSL证书、页面规则、邮件转发这些功能。
我推荐方案B。原因很实在：在申请阶段就把NS配置好，审核通过的那天，域名直接可用，不用再去迁移一次DNS。不过要提醒的是，如果用Cloudflare，申请审核时会检查你的NS是否有效，如果填错了会被拒。
2.3 申请材料别图省事，真实和具体是关键
eu.org的注册和申请都需要填个人信息。这里我说的“真实”不是说必须上传身份证，而是填写的姓名、地址、邮箱要看起来是个正常人在申请。
邮箱建议用Gmail、Outlook这类国际通用邮箱，QQ邮箱和163也能收到邮件，但如果你担心国际邮件进垃圾箱，提前把eu.org的域名加白名单。地址按拼音或英文格式填写，尽量详细到街道，方便验证。
用途描述是审核重点。不要只写“free domain”“test”这种词，跟你自己写的项目命无关，审核员不知道你是谁。合理的写法是：“用于托管我的个人技术博客，计划部署在GitHub Pages”或“用于我的开源项目展示页面和API调试”。让审核员觉得你是个真实用户，申请不是心血来潮。
3. 从注册账号到审核通过，完整操作记录
3.1 第一步：注册eu.org账号并激活
打开nic.eu.org，点页面里的注册入口，进入表单后填写名字、姓氏、邮箱、地址、国家、电话等基础信息。提交后系统会往邮箱发一封确认邮件，点里面的激活链接完成账号激活。
这里有个很多人被卡住的细节：确认邮件可能不会立刻到达，等个几分钟看看垃圾箱。如果一直没有，回到官网重新发送确认邮件。账号激活后先别急，你还没有权限直接申请域名，通常需要等系统完成账号审核。账号审核时间有快有慢，快的一两天，慢的可能一两周。
3.2 第二步：提交新域名申请，逐项说明
账号状态正常后，登录后台，找到“New Domain”之类的入口，开始申请域名。
表单里会要求填以下内容：
- 你想要的域名前缀，比如myblog；
- 域名的用途描述，建议写成两三行，说清楚你要做什么，代码仓库和项目主页有的话也放上去；
- 组织信息，个人申请就直接填自己的姓名；
- 地址信息，要和之前注册账号时保持一致；
- DNS服务器：如果选Cloudflare，就填ns1.cloudflare.com和ns2.cloudflare.com这两个（以你Cloudflare后台实际显示的为准）；如果选默认DNS，留意页面上的对应选项；
- 电话按国际格式填，国家码 + 区号 + 号码。
提交之后，系统会显示“等待审核”状态。从这一刻起，耐心开始计时。
3.3 第三步：等待审核期间，千万不要反复催
eu.org的审核周期波动很大。根据社区反馈，快的两三周，慢的两三个月都有，我见过最长拖了半年才下来的。所以如果你一周没收到通知，很正常，不用慌。
有个经验：审核期间别重复提交同一个域名，也别每天都登后台看状态。频繁的重复操作在审核员看来可能像滥用行为，反而不利。真有变化，官方会发邮件，你也可以偶尔登录后台看一眼状态。
等待期不是干等。建议把目标平台都准备好：GitHub Pages仓库已经配好、云服务器已经装好Nginx、Vercel项目已经导入。这样域名一旦激活，马上就能绑定跑起来。
3.4 第四步：通过之后，第一时间要做的检查
收到“Domain Activated”或类似的邮件后，别急着到处发链接，先做三个检查：
- 登录eu.org后台确认域名状态是Active；
- 如果你填了Cloudflare的NS，去Cloudflare后台看看域名状态是否从“Pending Nameserver”变成“Active”。有时需要手动点一下“Check nameservers now”强制刷新；
- 用
dig或在线工具查一下域名的NS记录，确认解析权已经生效。
都确认OK，你的免费永久域名就算正式到手了。
4. 把免费域名真正跑起来：DNS配置和三大高频用法
4.1 先在Cloudflare把解析基础打好
如果你的NS已经指向Cloudflare，登录Cloudflare后台找到域名，进去“DNS”管理页面添加记录。最常用的是A记录和CNAME记录：
- A记录：将@和www指向你的服务器IPv4地址；
- CNAME记录：将www指向主域名，或将子域指向其他服务商，比如GitHub Pages；
- MX记录和TXT记录：如果你要处理邮件，在后面加。
Cloudflare每条记录都有一个小云朵图标，灰色是仅DNS解析，橙色是开启代理（CDN）。开启代理后，访问者看到的是Cloudflare的IP，你的源站IP被隐藏，同时自动获得HTTPS。代价是某些网络环境下，代理节点可能绕路，访问速度不一定比直连快。我的建议是先用灰云把解析跑通，再开橙云测试对比，哪个快用哪个。
4.2 用法一：绑定GitHub Pages个人博客
这是最经典的玩法。假设你的GitHub用户名是username，仓库是username.github.io。
步骤：
- 到Cloudflare的DNS设置里，添加一条CNAME记录，主机名填@，目标填username.github.io；
- 如果想支持www，再添加一条CNAME，主机名填www，目标也可以填username.github.io；
- 去GitHub仓库的Settings → Pages → Custom domain，填你的完整域名，比如myblog.eu.org，点击Save；
- GitHub会提示你DNS配置不正确，不用担心，等解析生效就好了；
- 配置成功后，勾选“Enforce HTTPS”，GitHub会自动申请Let‘s Encrypt证书。
小坑提醒：如果你在Cloudflare开了橙色云朵，偶尔会遇到GitHub验证域名不通过的情况。我的处理办法是先把云朵点灰，验证通过后再开橙云，基本不出问题。
4.3 用法二：指向自己的云服务器，用Nginx托管站点
如果你的域名想直接解析到一台云服务器，操作更直接。先把A记录指向服务器IP，然后在服务器上配置Nginx。
给一个最简配置，假设站点文件放在/var/www/myblog：
server { listen 80; server_name myblog.eu.org www.myblog.eu.org; root /var/www/myblog; index index.html; location / { try_files $uri $uri/ =404; } }配置完执行nginx -t检查语法，没问题就重启Nginx。
接下来是HTTP证书。推荐用certbot自动申请Let‘s Encrypt证书：
sudo certbot --nginx -d myblog.eu.org -d www.myblog.eu.org如果你在Cloudflare开了橙色云朵代理，certbot默认的HTTP验证可能拿不到证书，因为代理把流量接管了。这时候要么临时灰云，要么用certbot的DNS验证插件。我个人的习惯是先把云朵灰了申请证书，再开橙云，省心。
4.4 用法三：内网穿透、API回调、OAuth测试场景
很多后端开发者会遇到一个需求：给朋友发一个链接，让对方直接访问到你本机的服务。没有公网IP的时候，通常用内网穿透工具。这类工具有些要求一个自定义域名作为访问入口，免费域名在这里就派上用场了。
以frp为例，你的云服务器上跑frps，家里的机器跑frpc，配置里把custom_domains设置成api.myblog.eu.org，然后到Cloudflare加一条A记录，把api子域指向frp服务器的公网IP。这样访问api.myblog.eu.org就能穿透到本地服务，不用记IP和端口。
同样的逻辑适用于企业微信/钉钉回调地址、第三方OAuth登录回调、GitHub Webhook接收等场景。很多平台要求回调地址必须是一个域名，不能是裸IP，免费域名就能帮你跑通整套流程。如果平台要求域名得提前验证归属，你只需要在DNS里加一条TXT记录就行。
5. 常见卡点与排查：审核被拒、解析不生效、国内访问时快时慢
5.1 审核被拒的常见原因，以及怎么补救
eu.org拒绝申请时，邮件内容往往很简短，有时就一句话。我总结下来，高频拒因主要是这几类。
| 拒绝原因 | 表现 | 解决办法 |
|---|---|---|
| DNS服务器缺失或填错 | 邮件提示Nameservers相关 | 确认Cloudflare的NS对不对，或者改用默认DNS |
| 用途描述太模糊 | 邮件说description不完整 | 重新提交时写清项目、平台、使用目的 |
| 信息看起来像机器人 | 地址/姓名随意 | 用一致的拼音、规范地址重新填 |
| 重复申请同一域名 | 同一个前缀反复提交 | 等被拒后再改一次，别隔几天就提交同一份 |
被拒不是终点，按提示修改后重新提交即可。真正要避免的是“被拒了不去改，直接换个名字再投”，同样会被判为滥用。
5.2 解析半天不生效，先别怪免费域名
绑定之后等了好久访问不了，大多数情况不是eu.org的问题，而是DNS自己没生效。排查按以下顺序来：
- 用
dig myblog.eu.org NS查看NS记录，确认返回的是Cloudflare的那两个NS； - 用
dig myblog.eu.org查看A记录/CNAME解析结果； - 登录Cloudflare看记录是不是“已保存”状态，TTL默认自动即可；
- 检查你本机和目标用户的网络缓存。可以换个网络（比如手机流量）测试，排除运营商DNS缓存。
Cloudflare的解析生效一般很快，几分钟到十几分钟，但全球完全同步可能要更久。别急着反复改记录，改一次T TL重新计时，反而更慢。
5.3 国内访问时快时慢，怎么处理比较现实
这个问题评论区经常有人问。eu.org的NS服务器在国外，但这只是影响解析过程，正常人访问一次后，解析结果会被本地缓存，真正影响速度的是你的源站位置和CDN线路。
如果你的源站是海外服务器，国内访问直连可能绕路；套了Cloudflare后，节点选择也不一定最优。我的实测经验是：同一个域名，开橙云代理和关掉代理，在不同运营商网络下速度表现完全不一样，有些地方橙云快，有些地方灰云直连快。最好的办法是自己模拟用户场景测试，别盲目听人说“必须开CDN”。
如果你准备绑国内服务器，那就要面对备案问题。免费域名在备案上通常不被接入商认可，所以个人练手项目我建议直接用海外轻量服务器或者纯静态托管，不碰备案这块，省心很多。
5.4 邮件服务被拒收？用转发绕过
免费域名做邮件服务器，很容易被Gmail、Outlook等大厂邮箱拒收。原因很简单：陌生域名的信誉度低，而免费域名又缺乏DKIM/SPF等完整邮件认证体系。
如果只是想要一个“看起来正式”的邮箱地址，不需要真的搭邮件服务器，可以用Cloudflare Email Routing，把比如admin@myblog.eu.org的邮件自动转发到你的个人邮箱。配置很简单：在Cloudflare的Email Routing页面填接收地址，再加一条MX记录（页面会给出）和一个TXT记录（用于验证所有权），全部免费。
这样你就有一个“自定义域名邮箱”了，虽然只能收不能发，但对多数个人场景足够用。
6. 除了eu.org，还有哪些免费域名方案值得了解
为了让你有横向对比，我列了一个表，覆盖几个真正还在运营的免费/低成本方案。
| 服务 | 域名形式 | 特点 | 适合场景 | 风险 |
|---|---|---|---|---|
| eu.org | yourname.eu.org | 老牌、免费、长期稳定 | 个人博客、项目展示、实验环境 | 审核慢、QA |
| DuckDNS | yourname.duckdns.org | 动态DNS，需定期确认 | 家庭宽带动态IP、物联网 | 有回收机制，不算永久 |
| is-a.dev | yourname.is-a.dev | 开发者社区运营，审核制 | 开发者个人主页、项目文档 | 条款严格，禁止非开发用途 |
| js.org | yourname.js.org | 开源项目专属 | 开源项目官网 | 必须提交GitHub仓库申请 |
| 付费域名首年活动 | 标准顶级域 | 首年十几到几十块 | 认真做的长期项目 | 续费恢复原价 |
DuckDNS本质上是一个动态DNS服务，适合没有固定公网IP的家宽场景，但它需要定期登录确认，否则域名会被回收，所以算不上“永久”。
is-a.dev和js.org都是面向开发者的免费域名，质量不错，但都有明确的用途限制。is-a.dev只允许个人开发者使用，js.org只允许开源项目申请，审核时都要提交证明。
至于Freenom那些老牌“免费顶级域”，目前基本处于无法正常注册的状态，就不推荐大家再去折腾了。
如果你试了一圈免费域名后，发现自己确实在认真做项目，我的建议是：核心业务最终还是落到一个付费的普通域名上，你完全可以把免费域名当试验田，跑通之后升级迁移。先用免费域名验证需求，再付费把根扎稳，这是成本最低的路径。
一些个人经验收尾
我手里这个eu.org域名，陪着我从一个写博客的菜鸟，一路用到接外包、跑内网穿透、给客户出Demo。最让我满意的一点不是“免费”，而是它足够“安静”——没有到期提醒，没有涨价公告，没有突然让你迁移到付费套餐。
最后分享两个小技巧。如果想把免费域名用得更顺手，可以给主域名配一个Cloudflare Email Routing，再在Nginx里做一个301跳转，把不带www的旧地址统一指到主站。这样别人看到你的域名时，体验已经和付费域名没什么区别了。
还有一点，eu.org这种免费服务能长久存在，靠的是大家共同维护，别拿它去做注册大量垃圾站、群发邮件这类事情。域名会因为滥用被封，整个eu.org也可能因为滥用而收紧政策。把免费做的东西用得体面一点，这个“永久”才能真的长久。
