客户端通常通过服务发现机制、配置文件或旨在共享服务器信息的网络协议来识别已连接的服务器。具体方法取决于系统架构，但常见的方法包括查询注册表、使用基于 DNS 的查找或依赖于预配置的服务器列表。例如，在微服务设置中，客户端可能会查询 Consul 或 etcd 等服务发现工具来查找可用的服务器。这些工具维护注册服务器及其网络位置（IP 地址和端口）的实时列表，允许客户端动态发现服务而无需硬编码详细信息。这确保了服务器扩展、缩减或发生故障时的灵活性。
一个实际的例子是基于 DNS 的发现。客户端可以使用 DNS SRV 或 A 记录将域名（例如，api.example.com）解析为服务器 IP 列表。例如，Kubernetes 服务使用 DNS 来公开端点：客户端查询 backend-service.namespace.svc.cluster.local 接收运行该服务的所有 pod 的 IP。同样，像 AWS 这样的云平台提供弹性负载均衡器 (ELB)，它分配一个 DNS 名称以跨服务器分配流量。客户端连接到 ELB 的 DNS 名称，ELB 在内部将请求路由到健康的实例。这抽象了跟踪各个服务器的复杂性，尤其是在服务器计数频繁变化的自动缩放环境中。
或者，客户端可以使用包含服务器地址的静态配置文件或环境变量。例如，客户端应用程序可以读取一个 servers.json 文件，其中列出了像 ["10.0.0.1:8080", "10.0.0.2:8080"] 这样的 IP。 虽然简单，但这种方法缺乏动态性，并且在服务器更改时需要手动更新。混合解决方案，例如将配置文件与定期 API 检查（例如，每 30 秒查询一次中央服务器）相结合，提供了一个折衷方案。像 Netflix Eureka 这样的工具就是这方面的例子：服务器向 Eureka 注册自己，客户端从 Eureka 的 API 获取服务器列表，并临时缓存它。这平衡了可靠性和适应性，确保客户端了解当前的服务器状态，而无需持续的网络开销。