统一域名格式的可靠方法及curl工具优化问题咨询

我管理着一个包含约10亿个独立网站的数据库，域名存在多种拼写形式：

example.com
subdomain.example.com
http://example.com
https://example.com
https://example.com/
https://sub.example.com
...

部分域名已过期且存在永久重定向，当前使用curl {domain} -s -L -I -o /dev/null -w '%{url_effective}'获取有效URL，但遇到以下问题：

• 少量域名存在curl无法解析的JS重定向（暂无需处理）
• 同时支持HTTP和HTTPS时，curl优先返回HTTP链接，希望优先HTTPS
• 非域名字符串也会被解析，如curl notadomain -s -L -I -o /dev/null -w '%{url_effective}'返回http://notadomain/，希望curl对此报错

问题解决方案 #

1. 优先使用HTTPS #

修改curl命令，强制默认使用HTTPS协议，仅当HTTPS连接失败时回退到HTTP：

# 先尝试HTTPS，失败则降级到HTTP
get_effective_url() {
    local domain="$1"
    # 优先尝试HTTPS
    local result=$(curl --proto-default https "$domain" -s -L -I -o /dev/null -w '%{url_effective}\n%{http_code}' 2>/dev/null)
    local effective_url=$(echo "$result" | head -n1)
    local http_code=$(echo "$result" | tail -n1)

    # HTTPS失败（状态码≥400或无返回）则尝试HTTP
    if [[ "$http_code" -ge 400 || -z "$effective_url" ]]; then
        effective_url=$(curl "$domain" -s -L -I -o /dev/null -w '%{url_effective}' 2>/dev/null)
    fi
    echo "$effective_url"
}

2. 过滤非域名/无效域名（重点解决） #

核心思路是先验证域名的DNS合法性，再执行curl请求，避免无效字符串被解析。结合dig做DNS解析验证：

validate_domain() {
    local domain="$1"
    # 清理输入：去掉协议前缀、路径、端口，提取纯域名
    local clean_domain=$(echo "$domain" | sed -E 's/^https?:\/\/(www\.)?//; s/(:[0-9]+)?\/.*$//')
    # 验证是否能解析到有效IPv4地址
    dig +short "$clean_domain" A | grep -E '^[0-9]+\.[0-9]+\.[0-9]+\.[0-9]+$' >/dev/null
    return $?
}

# 完整使用流程
process_domain() {
    local domain="$1"
    if validate_domain "$domain"; then
        local effective_url=$(get_effective_url "$domain")
        if [[ -n "$effective_url" ]]; then
            echo "$effective_url"
        else
            echo "Error: Failed to retrieve valid URL for $domain" >&2
        fi
    else
        echo "Error: Invalid domain or no DNS record found for $domain" >&2
        exit 1
    fi
}

方案潜在缺陷 #

• DNS解析开销大：10亿级数据量下，每个域名先做dig查询会大幅增加处理时间，网络和IO会成为瓶颈。
• 缓存一致性问题：无本地DNS缓存会重复查询，缓存过期则可能误判域名状态（如过期域名仍有缓存记录）。
• 域名清理不彻底：sed正则无法覆盖所有复杂URL格式（如带特殊字符的子域名），可能导致clean_domain提取错误。
• IPv6忽略：仅验证IPv4的A记录，部分仅支持IPv6的域名会被误判为无效。
• curl --proto-default局限性：某些服务器HTTPS证书无效时，curl会直接失败，无法自动降级到HTTP（需额外添加--insecure参数，但会引入安全风险）。

解析域名对应服务器IP的替代方案可行性评估 #

可行场景 #

• 初步批量过滤：如果仅需快速筛选有DNS记录的域名，解析IP比curl轻量得多，适合10亿级数据的初步清洗，能快速排除无效字符串和过期域名。
• 批量资源调度：若后续需对同一IP的多个域名做批量处理，提前解析IP可减少重复请求，节省资源。

局限性 #

• 无法处理重定向：解析IP只能获取域名当前指向的服务器IP，无法得到最终的有效跳转URL，无法满足核心需求。
• IP不等于有效服务：即使解析到IP，该IP可能未部署HTTP/HTTPS服务，或域名已过期但IP被其他服务占用，无法判断网站是否可用。
• CDN场景失效：多数域名使用CDN，解析到的是CDN节点IP而非源站IP，无法反映域名实际服务状态，也无法替代curl获取最终URL。

结论：解析IP仅适合作为前置过滤步骤，先筛选出有DNS记录的域名，再用优化后的curl命令处理，但无法替代curl获取有效URL的核心功能。

内容的提问来源于stack exchange，提问作者stkvtflw