URL转发简单来说，就是让一个网址自动跳转到另一个目标地址。点击短链接之后浏览器自动打开目标页面，绝大多数人不会关注跳转背后发生了什么，等到自己动手搭建这类服务，才会发现里面有不少细节需要留意。
短链接是最普遍的应用场景。微博发布长链接会占用大量字符空间，转换成t.cn/abc这类短地址，观感简洁还可以统计点击数据。域名迁移是另一类场景，旧域名打算停止续费，但担心老用户无法访问网站，就把整个旧域名转发指向新域名。营销推广场景也会用到，同一个活动页面投放到多个渠道，为每个渠道生成独立转发链接，后台统计不同渠道带来的访问量。
从技术层面解释，URL转发就是服务器收到访问请求，返回重定向状态码，通知浏览器跳转至新地址。301代表永久重定向，浏览器和搜索引擎会缓存跳转规则，后续访问直接访问目标地址。302属于临时重定向，每次访问都要先访问原地址再执行跳转。域名迁移场景适合使用301，营销活动短链接一般选用302，这是基础选择原则。两种状态码使用错误会影响SEO，301会把旧域名权重传递给新域名，302不会传递权重。
一套完整URL转发系统，功能不只是简单跳转。后台需要支持新建链接，为每条链接分配短码，短码支持随机生成，也可以由使用者自定义。链接要设置有效期，到期自动失效，避免活动结束很久之后依旧有人访问失效链接。点击统计属于核心功能，记录每一次访问的时间、来访IP、客户端标识、来源页面信息，汇总生成数据报表。进阶功能包含按访客地域或者设备类型跳转不同目标页面、A/B测试流量分配、访问密码校验、二维码生成、API批量创建链接。同时要做好防滥用机制，防止有人利用服务批量生成恶意短链接，导致域名被搜索引擎拉黑。
搭建URL转发系统有多种实现方案。轻量方案依靠Nginx直接配置转发。例如旧域名old.com跳转至new.com，在Nginx配置文件新增server块，监听80端口，域名填写old.com，写入return 301 https://new.com$request_uri。保存配置并重载服务，几秒就能完成部署。这种方案适合整个域名批量跳转，无法实现点击统计和短码生成。缺点是所有请求匹配同一套规则，没有管理后台，不能单独控制单条路径。
如果想要短链接全套能力，开源程序会更加合适。YOURLS基于PHP开发，属于老牌项目，部署完成自带管理后台，支持自定义短码、点击统计、API调用和插件扩展。Shlink采用PHP搭配PostgreSQL或者MySQL数据库，功能设计更现代化，原生支持REST API与命令行操作，还支持多域名接入。Kutt使用Node.js开发，界面简洁清爽，支持团队协作和自定义域名。这三款项目都提供Docker镜像，执行docker compose up命令就能快速启动。数据库可以选用SQLite或者MySQL，根据自身资源选择。部署完成后，将短域名解析到服务器，Nginx反向代理指向程序端口，配置SSL证书，整套服务就可以对外提供访问。
不想维护服务器的话，Cloudflare Workers是轻量化备选方案。编写几十行JavaScript代码，把短码和目标URL映射关系存放在KV存储，收到请求之后查询对应记录，返回302跳转。Workers免费额度支持每日十万次请求，个人使用足够。优势是不需要承担服务器开销，缺点是数据存储在Cloudflare侧，自定义程度比不上自建服务。
还有一项容易忽略的点，URL转发系统本身存在安全风险。短链接服务经常被钓鱼攻击利用，攻击者创建仿冒正规网站的短链接诱导用户点击。系统缺少内容审核机制的话，域名很容易被Google Safe Browsing标记，所有短链接都会失效。搭建的时候最好增加黑名单过滤，禁止跳转至已知恶意域名，至少增加举报入口。管理后台登录开启二次验证，API接口增加限流策略，防止被暴力破解或者刷接口，造成数据库压力过载。
自建转发系统有一项隐性成本，就是域名。短链接可信度和域名长度、品牌知名度直接相关。使用主域名下子路径例如example.com/go/abc，可信度会高于注册陌生后缀域名。但主域名通常还要承载其他业务，转发规则混在同一份Nginx配置文件，后期维护会变得杂乱。比较稳妥的做法是单独注册短域名专门做转发，主域名保留原有业务不受干扰。
最后说一个实操细节。Nginx配置301跳转，当目标URL包含中文或者特殊字符，需要提前完成URL编码，不然浏览器跳转失败。Apache的Redirect指令能够自动处理一部分特殊字符，Nginx的return 301需要自行保证$request_uri编码正常。这类问题平时很难碰到，一旦出现会直接返回404，排查耗时较长。部署完成之后，分别测试带参数链接、中文路径链接、锚点链接，确认跳转之后地址栏内容和预期一致，再正式上线。