1. 项目概述一个自建搜索代理的实践最近在折腾一个挺有意思的东西我把它叫做“MySearch-Proxy”。这个名字听起来可能有点技术范儿但说白了它的核心目标很简单在现有的网络环境下为自己搭建一个更干净、更可控、更聚焦的搜索体验层。这玩意儿不是什么复杂的商业产品而是一个可以自己部署、自己定制的代理服务专门用来处理和优化你的搜索请求。你可能会问直接用浏览器搜不就行了确实但用久了你会发现一些问题。比如搜索结果里夹杂着大量你不关心的推广信息不同搜索引擎的排序逻辑和内容侧重天差地别想做个横向对比得开好几个标签页有时候一些学术或技术类的小众网站内容在主流搜索引擎里反而被埋得很深。MySearch-Proxy 就是想解决这些“痒点”。它像一个智能的搜索调度中心你发出一条搜索指令它帮你同时向多个后端搜索引擎比如你可以配置谷歌、必应、DuckDuckGo甚至是某些垂直领域的站内搜索发起请求然后对返回的结果进行去重、过滤、重新排序最后以一个整洁统一的界面呈现给你。所有过程都在你自己的服务器上完成搜索历史和请求模式完全由你自己掌控。这个项目适合谁呢首先是那些对信息质量有要求的研发人员、技术写作者或学生他们需要高效、准确地获取技术文档、论文或解决方案。其次是注重隐私、不希望搜索行为被单一商业实体过度分析的用户。最后它也适合任何喜欢折腾、希望将常用网络服务“内化”为自己数字工具箱一部分的极客。实现它你需要一点服务器运维的基础比如会用 Linux 命令行了解基本的网络代理原理以及一些简单的脚本编写能力。接下来我就把自己搭建和优化这套系统的全过程包括设计思路、技术选型、踩过的坑和提升效率的技巧毫无保留地分享出来。2. 核心架构与设计思路拆解2.1 为什么是“代理”模式在构思之初我考虑过几种方案浏览器插件、本地桌面应用、或者是这种服务端代理。最终选择代理模式主要基于以下几个考量1. 全平台无感接入代理服务部署在服务器上任何能设置网络代理的设备电脑、手机、平板都可以立即使用无需在每个设备上安装单独的客户端。你只需要在系统的网络设置或浏览器的代理配置中指向你的服务器地址和端口即可。这种透明性带来了极大的便利。2. 计算与资源分离并发向多个搜索引擎发起请求、对大量返回的 HTML 页面进行解析和去重这些操作都是计算和 I/O 密集型的。如果放在浏览器插件或本地应用里会消耗用户本地设备的资源可能造成卡顿尤其是结果页数较多时。而服务器通常有更充沛的 CPU 和内存网络带宽也更好处理起来更从容用户体验更流畅。3. 规则集中化管理所有过滤规则比如屏蔽特定域名、关键词高亮、结果排序权重都可以在服务端统一配置和更新。一旦我需要调整“屏蔽所有内容农场类网站”的规则只需要在服务器上改一次所有连接的设备立即生效。如果每个客户端都维护一套规则同步和更新会是个噩梦。4. 隐私控制边界清晰代理服务器作为中间层可以直接剥离用户请求中的个人标识信息如浏览器指纹、部分 Cookie后再转发给后端搜索引擎。同时所有搜索日志如果需要保留也只存在于你自己掌控的服务器上不会泄露到第三方。这个清晰的隐私边界是本地应用难以提供的。2.2 技术栈选型与权衡确定了代理模式接下来就是技术选型。一个典型的搜索代理包含几个核心模块代理服务器本身、请求调度器、HTML 解析器、结果去重与排序算法、以及前端展示界面。1. 代理服务器基础我选择了Nginx作为反向代理的核心。原因很简单它性能极高、稳定性久经考验、配置灵活。通过 Nginx 的proxy_pass指令我可以轻松地将请求转发到不同的后端搜索引擎。同时Nginx 的sub_filter模块可以用来在返回的 HTML 内容中注入我们自己的 CSS 和 JavaScript以实现界面的美化与功能增强这是一种非侵入式的修改方式。2. 请求调度与逻辑处理纯 Nginx 配置虽然能转发请求但复杂的逻辑如并发请求、结果聚合处理起来很吃力。因此我引入了一个PythonFastAPI编写的中间层应用。FastAPI 异步特性好适合处理高并发的网络 I/O。这个中间层负责接收用户的搜索查询然后使用asyncio和aiohttp库并发地向预配置的多个搜索引擎 URL 发起请求。这里有个关键点模拟真实的浏览器请求头User-Agent、Accept-Language等以避免被搜索引擎识别为机器人而返回验证码或简化版页面。3. HTML 解析从搜索引擎拿回来的是完整的 HTML 页面我们需要从中精准地提取出标题、链接、摘要这些结构化信息。BeautifulSoup4和lxml是这个领域的黄金组合。BeautifulSoup 提供了友好的 Pythonic API而 lxml 作为解析后端速度非常快。我们需要为每个目标搜索引擎编写一个专门的“解析器”因为它们的 HTML 结构差异很大。例如谷歌结果通常包裹在div class”g”的标签里而必应的结构则完全不同。4. 去重与排序这是体现代理“智能”的地方。去重主要基于结果的URL和标题的语义相似度。简单的 URL 匹配可以去掉完全相同的链接。对于标题相似度我使用了TF-IDF 向量化结合余弦相似度计算的方法。虽然不如大型 NLP 模型精准但对于识别“同一事件的不同报道”或“同一软件的不同下载站”这类重复结果效果已经足够好且计算开销小。 排序则是一个综合考量的过程。基础的相关性分数由原始搜索引擎的排名决定例如谷歌第一页的结果通常比第五页的相关性更高。在此基础上我会加入自定义的权重域名权重我可以手动给stackoverflow.com、developer.mozilla.org等技术站点更高的权重让它们排名靠前。关键词惩罚如果结果链接或摘要中包含“下载站”、“破解”、“广告密集”等特征词会被降低权重。时效性加分对新闻类搜索发布日期较新的结果会获得加分。5. 前端展示为了极致轻量和控制力我没有用 React/Vue 等重型框架而是用了简单的HTML JavaScript (原生) Tailwind CSS。前端页面通过 Fetch API 与后端的 FastAPI 应用通信。Tailwind CSS 让我能快速构建出一个干净、响应式的界面而不需要写大量自定义的 CSS。结果以卡片形式呈现清晰展示来源搜索引擎、标题、摘要和链接。注意技术选型没有银弹。这里选择 Python 和 Nginx 是基于快速开发和部署的考虑。如果你的场景对并发性能要求极高每秒数千请求或许可以考虑 Go 语言重写核心代理逻辑。但对于个人或小团队使用当前栈完全够用且生态丰富出了问题也容易排查。3. 核心模块实现细节与配置3.1 Nginx 反向代理配置精讲Nginx 在这里扮演着流量入口和初级路由的角色。它的配置直接影响了服务的稳定性和性能。# /etc/nginx/sites-available/mysearch-proxy server { listen 80; server_name search.your-domain.com; # 替换为你的域名 # 强烈建议启用 HTTPS使用 Let‘s Encrypt 免费证书 # listen 443 ssl; # ssl_certificate /path/to/fullchain.pem; # ssl_certificate_key /path/to/privkey.pem; location / { # 将根路径的请求转发给后端的 FastAPI 应用 proxy_pass http://127.0.0.1:8000; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; } location ~ ^/proxy/(?enginegoogle|bing|duckduckgo)/ { # 这是一个关键技巧通过路径来动态选择后端搜索引擎 # 用户请求 /proxy/google/search?qhello会被转发到谷歌 internal; # 标记为内部位置只允许后端应用访问防止用户直接调用 resolver 8.8.8.8; # 配置DNS解析器 set $target_host ; set $target_url ; # 根据 $engine 变量设置不同的代理目标 if ($engine google) { set $target_host www.google.com; set $target_url https://www.google.com/search?$query_string; } if ($engine bing) { set $target_host www.bing.com; set $target_url https://www.bing.com/search?$query_string; } if ($engine duckduckgo) { set $target_host duckduckgo.com; set $target_url https://duckduckgo.com/html/?$query_string; } proxy_pass $target_url; proxy_set_header Host $target_host; # 关键设置一个真实的 User-Agent模仿 Chrome 浏览器 proxy_set_header User-Agent Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/91.0.4472.124 Safari/537.36; proxy_set_header Accept-Language en-US,en;q0.9; proxy_hide_header Set-Cookie; # 隐藏后端返回的 Cookie避免污染 proxy_hide_header Cache-Control; add_header X-Search-Proxy-Engine $engine; # 自定义头便于调试 } }配置要点解析内部位置 (internal):/proxy/这个路径下的请求被标记为internal意味着它只能由 Nginx 内部的其他请求比如我们后端 FastAPI 发出的子请求访问而不能由用户直接从浏览器访问。这增加了安全性防止接口被滥用。动态代理目标: 利用 Nginx 的location正则捕获和set指令我们实现了根据 URL 路径动态切换代理后端。这种设计比写死多个location块更清晰也更容易扩展新的搜索引擎。请求头伪装:proxy_set_header User-Agent是重中之重。使用一个常见的桌面浏览器 User-Agent能极大降低被搜索引擎识别为爬虫的风险。Accept-Language头也会影响搜索引擎返回的语言版本。隐藏不必要头部:proxy_hide_header用于移除后端返回的某些 HTTP 头比如Set-Cookie。我们不希望搜索引擎的 Cookie 被设置到用户的浏览器中这既是为了隐私也是为了避免潜在的冲突。3.2 FastAPI 后端异步调度与聚合引擎后端应用是大脑它协调所有搜索任务。我使用 FastAPI 因为它自动生成的交互式 API 文档Swagger UI对调试非常友好。# main.py 核心部分 from fastapi import FastAPI, Query, HTTPException from fastapi.responses import HTMLResponse from fastapi.staticfiles import StaticFiles import aiohttp import asyncio from bs4 import BeautifulSoup from urllib.parse import quote_plus import re from typing import List, Dict import hashlib app FastAPI(title”MySearch-Proxy API”) # 挂载前端静态文件 app.mount(“/static”, StaticFiles(directory”static”), name”static”) # 搜索引擎配置 SEARCH_ENGINES { “google”: {“url”: “http://localhost/proxy/google/search”, “name”: “Google”}, “bing”: {“url”: “http://localhost/proxy/bing/search”, “name”: “Bing”}, “duckduckgo”: {“url”: “http://localhost/proxy/duckduckgo/”, “name”: “DuckDuckGo”}, } async def fetch_search_results(session: aiohttp.ClientSession, engine: str, query: str) - List[Dict]: “””并发获取单个搜索引擎的结果””” config SEARCH_ENGINES[engine] try: async with session.get(config[“url”], params{“q”: query}, timeout10) as resp: if resp.status 200: html await resp.text() return parse_results(engine, html) # 调用对应的解析函数 else: print(f”Engine {engine} returned status {resp.status}”) return [] except asyncio.TimeoutError: print(f”Engine {engine} timeout”) return [] except Exception as e: print(f”Error fetching from {engine}: {e}”) return [] def parse_results(engine: str, html: str) - List[Dict]: “””解析HTML提取结构化结果。这里以谷歌为例””” soup BeautifulSoup(html, ‘lxml’) results [] if engine “google”: # 谷歌的搜索结果通常包含在 div class‘g’ 中 for item in soup.select(‘div.g’): link_elem item.select_one(‘a[href^”http”]’) title_elem item.select_one(‘h3’) snippet_elem item.select_one(‘div.VwiC3b’) if link_elem and title_elem: url link_elem[‘href’] # 过滤掉非http/https或谷歌自家的链接如图片、视频搜索 if not re.match(r’^https?://’, url) or ‘google.com/’ in url: continue title title_elem.get_text(stripTrue) snippet snippet_elem.get_text(stripTrue) if snippet_elem else ” results.append({ “title”: title, “url”: url, “snippet”: snippet, “engine”: “google”, “source”: “Google”, }) # … 此处需要为 bing, duckduckgo 编写类似的解析逻辑 return results app.get(“/api/search”) async def search_all(q: str Query(…, min_length1)): “””主搜索接口并发查询所有引擎””” if not q: raise HTTPException(status_code400, detail”Query cannot be empty”) async with aiohttp.ClientSession() as session: tasks [] for engine in SEARCH_ENGINES.keys(): task fetch_search_results(session, engine, q) tasks.append(task) # 并发执行所有搜索任务 results_lists await asyncio.gather(*tasks, return_exceptionsTrue) # 扁平化并聚合结果 all_results [] for lst in results_lists: if isinstance(lst, list): all_results.extend(lst) # 去重和排序 deduplicated_results deduplicate_by_url_and_title(all_results) sorted_results custom_ranking(deduplicated_results, q) return {“query”: q, “results”: sorted_results} def deduplicate_by_url_and_title(results: List[Dict]) - List[Dict]: “””基于URL和标题相似度去重””” seen_urls set() seen_title_hashes set() unique_results [] for result in results: url result[“url”] # 1. 精确URL去重 if url in seen_urls: continue seen_urls.add(url) # 2. 简单标题去重取前50字符的MD5可优化为语义相似度 title_key hashlib.md5(result[“title”][:50].encode()).hexdigest() if title_key in seen_title_hashes: continue seen_title_hashes.add(title_key) unique_results.append(result) return unique_results def custom_ranking(results: List[Dict], query: str) - List[Dict]: “””自定义排序算法””” # 这里实现一个简单的加权评分系统 for result in results: score 0 # 基础分模拟原始排名这里简化处理实际可以从HTML中解析排名信息 score 100 # 域名权重加成 if ‘stackoverflow.com’ in result[“url”]: score 50 if ‘github.com’ in result[“url”]: score 30 if ‘developer.mozilla.org’ in result[“url”]: score 40 # 关键词惩罚 penalty_keywords [‘download’, ‘crack’, ‘serial’, ‘注册码’] for kw in penalty_keywords: if kw in result[“title”].lower() or kw in result[“snippet”].lower(): score - 80 break # 查询词在标题中的出现位置越靠前越好 try: title_lower result[“title”].lower() idx title_lower.find(query.lower()) if idx ! -1: score max(0, 30 - idx) # 位置越靠前加分越多 except: pass result[“_score”] score # 添加一个临时评分字段 # 按评分降序排序 results.sort(keylambda x: x.get(“_score”, 0), reverseTrue) # 移除临时字段 for r in results: r.pop(“_score”, None) return results app.get(“/”, response_classHTMLResponse) async def read_index(): “””返回前端主页面””” with open(“static/index.html”, “r”) as f: return HTMLResponse(contentf.read())代码逻辑解析异步并发 (asyncio.gather): 这是性能关键。asyncio.gather允许我们同时发起所有搜索引擎的请求总耗时约等于最慢的那个引擎的响应时间而不是它们的总和。结构化解析: 每个搜索引擎都需要一个独立的parse_results函数。这是因为它们的 HTML 结构差异巨大。编写这个函数需要仔细分析目标网站的页面源码通常需要用到 Chrome 开发者工具的“检查”功能。这个过程可能比较繁琐且需要定期维护因为搜索引擎可能会改版。去重策略: 示例中使用了 URL 精确匹配和标题简单哈希去重。在实际生产中你可能需要更智能的语义去重比如使用jieba中文或nltk英文进行分词然后计算 TF-IDF 向量和余弦相似度当相似度超过一个阈值如0.8时视为重复。评分排序:custom_ranking函数展示了如何将业务逻辑融入排序。你可以根据自己的偏好无限扩展这个评分规则。例如给.edu、.gov域名加分给某些广告特征明显的摘要减分等。实操心得在编写解析器时最头疼的是搜索引擎的反爬机制。除了伪装 User-Agent有时还需要处理 JavaScript 渲染的内容谷歌的部分结果可能是动态加载的。对于简单情况可以尝试在请求头中添加Accept: text/html并确保 Referer 头设置合理。如果遇到严重封锁可能需要引入更复杂的策略如使用playwright或selenium进行无头浏览器渲染但这会大幅增加资源消耗和延迟仅作为最后手段。4. 前端界面与交互实现前端的目标是简洁、快速、信息清晰。我们使用原生 JavaScript 来保持轻量。!– static/index.html – !DOCTYPE html html lang”en” head meta charset”UTF-8” meta name”viewport” content”widthdevice-width, initial-scale1.0” titleMySearch-Proxy/title script src”https://cdn.tailwindcss.com”/script style .result-card:hover { background-color: #f8fafc; } .loader { border-top-color: #3b82f6; animation: spin 1s linear infinite; } keyframes spin { 0% { transform: rotate(0deg); } 100% { transform: rotate(360deg); } } /style /head body class”bg-gray-50 min-h-screen” div class”container mx-auto px-4 py-8” header class”text-center mb-10” h1 class”text-4xl font-bold text-gray-800 mb-2”MySearch-Proxy/h1 p class”text-gray-600”一个干净、聚合、可定制的搜索界面/p /header main div class”max-w-3xl mx-auto” div class”relative” input type”text” id”searchInput” placeholder”输入关键词开始搜索 (例如: Python FastAPI 教程)…” class”w-full px-6 py-4 text-lg border border-gray-300 rounded-full shadow-sm focus:outline-none focus:ring-2 focus:ring-blue-500 focus:border-transparent” autocomplete”off” button onclick”performSearch()” class”absolute right-3 top-3 bg-blue-600 hover:bg-blue-700 text-white font-semibold py-2 px-6 rounded-full transition duration-200” 搜索 /button /div div class”mt-4 flex flex-wrap gap-2 justify-center” id”engineBadges” !– 搜索引擎标签动态激活 – span class”engine-badge px-3 py-1 rounded-full text-sm border border-blue-500 text-blue-500 bg-blue-50”># /etc/systemd/system/mysearch-proxy.service [Unit] DescriptionMySearch-Proxy Backend Service Afternetwork.target [Service] Userwww-data # 使用一个非root用户运行更安全 Groupwww-data WorkingDirectory/opt/mysearch-proxy # 你的项目目录 Environment”PATH/opt/mysearch-proxy/venv/bin” # 如果你用了虚拟环境 ExecStart/opt/mysearch-proxy/venv/bin/uvicorn main:app –host 0.0.0.0 –port 8000 –proxy-headers Restartalways # 进程崩溃后自动重启 RestartSec3 [Install] WantedBymulti-user.target部署步骤将项目代码上传至服务器/opt/mysearch-proxy。安装 Python 依赖pip install -r requirements.txt(需包含 fastapi, uvicorn, aiohttp, beautifulsoup4, lxml 等)。配置好 Nginx 配置文件并启用sudo ln -s /etc/nginx/sites-available/mysearch-proxy /etc/nginx/sites-enabled/然后sudo nginx -t测试配置sudo systemctl reload nginx重载。启用并启动后端服务sudo systemctl enable –now mysearch-proxy.service。使用sudo systemctl status mysearch-proxy和sudo journalctl -u mysearch-proxy -f来检查状态和跟踪日志。5.2 性能优化策略随着使用量增加性能问题会浮现。以下是几个关键的优化方向1. 请求缓存对相同的搜索查询没必要每次都去骚扰搜索引擎。可以在 FastAPI 应用层加入缓存。对于个人使用一个简单的内存缓存如cachetools库的TTLCache就够用设置一个合理的 TTL例如 5-10 分钟。from cachetools import TTLCache search_cache TTLCache(maxsize1000, ttl600) # 缓存1000个查询有效期10分钟 app.get(“/api/search”) async def search_all(q: str Query(…)): cache_key f”{active_engine}:{q}” if cache_key in search_cache: return search_cache[cache_key] # … 正常搜索逻辑 … result {“query”: q, “results”: sorted_results} search_cache[cache_key] result return result2. 异步解析优化HTML 解析BeautifulSoup是 CPU 密集型操作如果在主事件循环中同步进行可能会阻塞其他异步任务。可以考虑将解析任务丢到线程池中执行避免阻塞。import concurrent.futures parse_executor concurrent.futures.ThreadPoolExecutor(max_workers4) async def fetch_and_parse(session, engine, query): html await fetch_html(session, engine, query) # 将解析任务提交到线程池 loop asyncio.get_event_loop() results await loop.run_in_executor(parse_executor, parse_results, engine, html) return results3. 限制与超时必须为向外部的搜索引擎请求设置严格的超时如 10 秒并使用asyncio.gather的return_exceptionsTrue参数确保一个引擎的失败不会导致整个搜索失败。同时可以考虑限制用户每分钟的搜索频率防止滥用。5.3 安全与隐私加固自建服务安全不容忽视。启用 HTTPS使用 Let‘s Encrypt 为你的域名申请免费 SSL 证书并在 Nginx 中强制启用 HTTPS。这能加密用户浏览器和你服务器之间的所有通信防止搜索词被窃听。访问控制如果你的搜索代理仅供自己或小团队使用最简单的办法是在 Nginx 层面配置HTTP 基本认证或者只允许特定的 IP 地址访问。# Nginx 基本认证 auth_basic “Restricted Access”; auth_basic_user_file /etc/nginx/.htpasswd; # 使用 htpasswd 命令创建此文件输入净化对用户输入的搜索词进行基本的清理防止 XSS 攻击。虽然我们的后端主要是转发但净化输入是好习惯。FastAPI 的Query参数会自动处理一些基础问题。日志管理明确你的日志策略。如果你关心隐私可以选择不记录搜索词或者只记录聚合后的匿名统计信息如每天搜索次数。确保服务器日志文件有适当的权限和滚动策略避免磁盘被撑满。5.4 扩展性与自定义这是 MySearch-Proxy 最有趣的部分——你可以无限扩展它。添加新的搜索引擎只需在SEARCH_ENGINES字典和 Nginx 配置中添加一个新条目并为其编写对应的parse_results函数。你可以加入Wikipedia、GitHub、甚至公司内部的文档系统。自定义过滤规则在custom_ranking函数中你可以加入任何你想要的逻辑。比如我写了一条规则自动屏蔽所有 URL 中包含特定广告联盟模式域名的结果。结果后处理你可以在结果返回给用户前对摘要进行高亮显示搜索词或者自动为某些特定网站如 YouTube、GitHub的链接生成一个快速预览图标。聚合其他服务这个框架不限于搜索。你可以想象将天气查询、词典翻译、快递跟踪等 API 调用聚合到同一个简洁的界面中打造一个真正的个人信息门户。6. 常见问题与故障排查实录在实际搭建和运行过程中你几乎一定会遇到下面这些问题。这里是我踩过坑后的经验总结。问题一Nginx 代理返回 502 Bad Gateway 错误。排查思路检查后端服务是否运行sudo systemctl status mysearch-proxy。如果没运行查看日志journalctl -u mysearch-proxy -n 50。检查端口和网络确认 FastAPI 应用是否在0.0.0.0:8000监听。使用netstat -tlnp | grep :8000查看。确保防火墙如 UFW放行了 8000 端口。检查 Nginx 错误日志sudo tail -f /var/log/nginx/error.log。最常见的错误是connect() failed (111: Connection refused)这指向后端服务未启动或网络不通。检查 Nginx 代理配置确保proxy_pass的地址和端口正确。如果是本地服务使用http://127.0.0.1:8000比http://localhost:8000更可靠。问题二从某些搜索引擎获取的结果为空或解析失败。排查思路验证原始请求首先手动在服务器上用curl命令模拟请求看看能否拿到正常的 HTML。例如curl -A “Mozilla/5.0…” “https://www.google.com/search?qtest”。如果返回的是验证码页面或简化版页面说明请求头伪装不够。增强请求头在 Nginx 的proxy_set_header或 Python 的aiohttp请求中添加更多常见的浏览器头部如Accept、Accept-Encoding、Referer可以设置为搜索引擎的域名。检查解析器搜索引擎的页面结构可能已经改变。将获取到的 HTML 保存到文件仔细检查你用来定位结果的 CSS 选择器是否还正确。可能需要更新parse_results函数中的选择器字符串。处理动态内容如果页面大量依赖 JavaScript 渲染现代网站越来越常见简单的 HTTP 请求获取的 HTML 是不完整的。这时需要评估是否引入无头浏览器但务必谨慎因为资源消耗巨大。问题三搜索响应速度很慢。排查步骤定位瓶颈在代码中添加计时器分别记录“网络请求总耗时”和“解析聚合耗时”。通常瓶颈在网络 I/O。检查超时设置确保为每个引擎的请求设置了合理的超时如 8-10 秒。一个引擎的卡顿会拖累整个并发请求。启用缓存如 5.2 节所述引入缓存对重复查询的提升是立竿见影的。检查服务器资源使用top或htop命令查看服务器 CPU 和内存使用情况。如果解析任务太重考虑使用线程池优化。考虑地理延迟如果你的服务器在海外访问国内搜索引擎如百度可能会很慢。反之亦然。考虑为不同区域的引擎使用不同的代理策略或者接受其延迟。问题四服务运行一段时间后内存占用越来越高。可能原因与解决内存泄漏检查 Python 代码中是否有全局变量在无限累积数据比如一个全局的 List 在不断 append。缓存如果未设置大小或 TTL也可能导致内存增长。确保使用TTLCache这类有自动淘汰机制的缓存。解析器内存未释放BeautifulSoup 解析大的 HTML 文档会生成复杂的 DOM 树。在处理完一个页面后确保及时将变量引用置为None或让它们离开作用域以便垃圾回收。监控与重启对于长期运行的服务可以配置一个简单的监控脚本当内存超过阈值时自动重启后端进程systemctl restart mysearch-proxy。这虽然粗暴但对于个人项目往往是有效的兜底方案。搭建这样一个 MySearch-Proxy 的过程更像是一次对互联网信息获取方式的个性化改造。它没有改变互联网上的任何内容只是在你和浩瀚信息海洋之间架设了一个属于你自己的、可编程的过滤器与调度站。从最初的简单转发到加入智能排序和过滤再到为它优化性能和界面每一步的调整都让这个工具更贴合我自己的使用习惯。最终它节省的不仅仅是打开多个标签页的时间更是一种心流不被频繁打断的专注。如果你也对默认的搜索体验感到些许不适不妨花一个周末从最基础的 Nginx 代理配置开始亲手搭建一个。你会发现掌控自己数字生活的一部分感觉真的很好。