发布时间：2026/10/6 12:57:39 分类：行业资讯 作者：阿非苏格编辑部

没固定ip怎么做网站：3个免费工具搞定动态域名解析

很多老板觉得网站必须买公网IP，其实这是误区。

我见过太多企业官网，花大钱定制开发，结果因为没固定IP，服务器迁移时域名解析全乱了。

更扎心的是，那些用免费工具搭的站，反而因为部署灵活、维护成本低，活得比大制作还久。

今天不讲虚的，直接上干货，聊聊怎么在没固定IP的环境下，用免费工具把网站稳稳当当跑起来。

项目背景：从“被绑架”到“自由身”的挣扎

三年前，我接手了一个传统制造企业的官网改版项目。

客户很强势，要求网站必须高大上，最好有3D展示效果。

我们团队也是老手，用ThinkPHP+Vue做了一套定制系统，UI做得确实漂亮。

但上线前遇到了个大麻烦：客户原有的IDC机房要搬迁，新机房给的是内网IP，没有固定公网IP。

以前的做法是，要么加钱买固定IP，要么找代理。

但这次预算卡得死，而且客户要求一周内必须切换上线，不能停机。

当时项目组负责人老张愁得头发都白了几根，说：“没固定IP，DNS怎么解析？CDN怎么回源？”

这时候，实习生小刘提了一嘴：“要不试试动态域名解析？或者用免费对象存储？”

这一提，思路就打开了。

我们重新评估需求，发现客户核心诉求是“访问稳定”和“成本可控”，而不是非要绑定在某个物理服务器上。

于是，我们决定抛弃传统的“固定IP+独立服务器”模式，转向“动态域名+云托管”的轻量化架构。

这也是很多中小企业在2026年建站时最应该关注的趋势：去IP化，重服务。

技术选型：三个免费工具的组合拳

既然没有固定IP，我们的技术选型必须围绕“动态”和“解耦”展开。

经过对比测试，我们锁定了三个完全免费且稳定的工具，形成了我们的核心方案。

1. 动态DNS服务：让域名追着IP跑

既然IP会变，那就让域名自动跟踪IP。

我们选用了阿里云云解析DNS的免费套餐，配合DDNS脚本。

虽然阿里云云解析的基础服务是免费的，但高级功能收费。

对于个人或小团队，我们可以利用免费的DDNS客户端，比如No-IP或DynDNS的免费层，或者自己写脚本调用API。

在这里，我推荐直接使用阿里云官方文档中提供的API接口，虽然需要注册账号，但基础解析是免费的，且稳定性极高。

通过脚本，每5分钟检测一次内网出口IP的变化，如果变化，立即调用API更新域名A记录。

2. 静态资源托管：彻底甩掉Web服务器

原来的ThinkPHP系统是动态的，依赖PHP-FPM和MySQL。

在没有固定IP且资源受限的情况下，维护动态环境太痛苦。

我们决定将前端重构为纯静态站点（Static Site），后端接口单独剥离，部署在Serverless函数上。

前端静态文件托管到GitHub Pages或Vercel，这两个平台都提供免费的HTTPS和全球CDN。

这意味着，你的网站前端访问速度，取决于用户离最近的CDN节点有多近，而不是取决于你服务器在哪里。

3. Serverless后端：按量付费，甚至免费额度够用

后端API接口，我们迁移到了Cloudflare Workers或阿里云函数计算FC的免费额度层。

Cloudflare Workers免费额度极其慷慨，每天10万次请求，对于官网这种流量级别，完全够用。

而且，Workers是边缘计算，代码直接运行在CDN节点上，没有冷启动问题，响应速度极快。

关键决策点：

组件	传统方案	本案例方案	优势
域名解析	固定A记录	DDNS动态更新	适应IP变化，无需固定IP
前端托管	Nginx + Apache	GitHub Pages/Vercel	免费HTTPS，全球加速，免运维
后端接口	PHP + MySQL	Cloudflare Workers	无服务器，免费额度大，高并发
数据库	自建MySQL	Supabase/Cloudflare KV	免费，自动备份，免运维

核心实现：代码与配置细节

光说方案不行，得看怎么落地。

这里分享两个核心代码片段，都是我们在项目中实际使用的。

1. DDNS自动更新脚本

我们写了一个Python脚本，部署在拥有公网出口的路由器或内网服务器上，定期执行。

import requests
import socket
import time# 阿里云DNS API参数
ACCESS_KEY_ID = 'your_access_key_id'
ACCESS_KEY_SECRET = 'your_access_key_secret'
DOMAIN = 'example.com'
RECORD_NAME = 'www'def get_public_ip():"""获取当前公网IP"""try:response = requests.get('https://httpbin.org/ip')return response.json()['origin']except Exception as e:print(f"Error getting IP: {e}")return Nonedef update_dns(new_ip):"""调用阿里云API更新A记录"""# 注意：实际项目中应使用阿里云SDK，这里仅为逻辑演示# 参考阿里云官方文档：https://help.aliyun.com/product/29746.htmlurl = "https://alidns.aliyuncs.com"params = {"Action": "UpdateRecord","DomainName": DOMAIN,"RR": RECORD_NAME,"Type": "A","Value": new_ip,"AccessKeyId": ACCESS_KEY_ID,"Signature": "calculated_signature" # 需计算签名}try:response = requests.post(url, data=params)if response.status_code == 200:print(f"DNS updated to {new_ip}")else:print(f"Update failed: {response.text}")except Exception as e:print(f"API Error: {e}")if __name__ == '__main__':while True:current_ip = get_public_ip()if current_ip:# 这里简化了逻辑，实际需先查询当前DNS值，对比后再更新update_dns(current_ip)time.sleep(300) # 每5分钟检查一次

注：生产环境建议使用阿里云官方SDK，处理签名和异常更稳健。

2. Cloudflare Workers 后端接口

我们将原来的PHP接口改写成了JavaScript，部署在Workers上。

export default {async fetch(request, env) {const url = new URL(request.url);if (url.pathname === '/api/products') {// 从 Cloudflare KV 获取产品数据const products = await env.PRODUCTS_KV.get('list', 'json');return new Response(JSON.stringify(products), {headers: { 'Content-Type': 'application/json' }});}if (url.pathname === '/api/contact') {// 处理表单提交，发送到 Email Routing 或 Queueconst formData = await request.formData();const email = formData.get('email');const message = formData.get('message');// 调用邮件服务或存入队列await env.MAILER_QUEUE.send({ email, message });return new Response(JSON.stringify({ success: true }), {headers: { 'Content-Type': 'application/json' }});}return new Response('Not Found', { status: 404 });}
}

这个配置非常轻量，没有任何数据库连接池管理的烦恼，KV存储足够支撑官网级的数据读取。

上线与优化：踩过的坑与解决方案

方案听起来很美，但上线过程并不顺利。

坑一：DDNS延迟导致的DNS污染

刚开始，我们发现用户访问时，有时解析到旧IP，导致连接超时。

原因是DNS TTL（生存时间）设置过长，默认是600秒（10分钟）。

解决方案：

我们将阿里云DNS的TTL调整为60秒。

虽然这会增加DNS服务器查询频率，但对于官网这种低频访问场景，完全可接受。

同时，在DDNS脚本中，只有当IP真正变化时才触发更新，避免频繁无效调用。

坑二：HTTPS证书配置麻烦

GitHub Pages和Vercel自动提供HTTPS，但Workers的HTTPS需要单独配置。

起初我们试图用自签名证书，结果浏览器全是红色警告，用户体验极差。

解决方案：

使用Cloudflare的免费通配符证书。

在Cloudflare Dashboard中，开启“Always Use HTTPS”，并配置“HSTS”头。

这样，无论是静态前端还是动态后端，都自动覆盖在同一个SSL证书下，无需手动维护。

坑三：跨域问题（CORS）

前端在Vercel，后端在Cloudflare Workers，不同域，必然有CORS问题。

解决方案：

在Workers代码中，添加CORS头：

const corsHeaders = {'Access-Control-Allow-Origin': '*','Access-Control-Allow-Methods': 'GET, POST, OPTIONS','Access-Control-Allow-Headers': 'Content-Type'
};// 在响应中合并 corsHeaders
return new Response(JSON.stringify(data), {headers: { ...corsHeaders, 'Content-Type': 'application/json' }
});

同时，在Nginx或Vercel配置中，预检请求（OPTIONS）直接返回204。