Using a Proxy with Bluesky: XRPC, Stream Connection and the Exit Decision

The Bluesky client looks like a single application on screen, but the protocol behind it splits the work across three separate roles: the server that holds your account data, the relay layer that collects changes across the network, and the indexing layer that makes the feed readable. When you define a proxy, these roles may not all fall under the same rule.

The practical consequence is this: if you enable a proxy in the browser and can sign in but the timeline stays empty, the problem is usually not authentication but the queries to the indexing layer falling outside the rule. Likewise, when listening to the live stream with a desktop tool, a connection that drops at regular intervals is most often related to the proxy closing idle tunnels.

The sections below first unpack this structure, then move on to exit type selection, stream connections, rate limit behaviour and corporate network restrictions.

Which endpoints does a Bluesky session spread across?

In the AT Protocol your account is hosted on a personal data server (PDS). Operations such as signing in, writing a post or changing your follow list are write operations and go directly to this server. In the default setup this server is the domain Bluesky hosts itself; for users running their own server it is an entirely different domain. If you write your proxy rule only against the domain where the application opens, write requests on an account using its own server can fall outside the rule.

The queries that populate the timeline, search results and profile pages are read queries and come from a separate indexing layer. Because this layer collects posts across the network and makes them queryable, it is usually the side the client talks to most heavily. Images and link previews, meanwhile, arrive over a third path, from a static file service.

All of these calls use a common call form: paths over HTTPS beginning with /xrpc/ and dot-separated namespaces. So on the protocol side there is a single scheme, but that scheme is spread across more than one host name. The correct behaviour on the proxy side is to route the process running the application in its entirety, or to write a rule covering all the relevant domains.

Identity, domain verification and the role of DNS

On Bluesky the username takes the form of a domain and is bound in the background to a persistent identifier. When you want to bind your own domain as your username, verification is done in one of two ways: adding a TXT record to your domain, or publishing a small text file at a specific path on your server. In both methods, resolution at the moment of verification is performed by the platform, not from your network.

The domain resolution the client sees, by contrast, happens on your side, and this is the most overlooked point in a proxy setup. If you use an HTTP proxy, the host name is passed to the proxy in the request line and resolution is mostly done on the proxy side. With SOCKS5 there are two different behaviours: the client can resolve the name itself and send an IP, or it can leave the name as is to the proxy. In the former, your real DNS server sees which host you are going to.

What this difference means and how to configure it on the client side is explained step by step in the article where DNS is resolved in SOCKS5 . After setup, confirm with a leak test that resolution really is happening on the side you expect; the value shown on the client's settings screen and the behaviour observed on the network do not always match.

One caveat: you do not need to turn the proxy off while performing domain verification, because the platform does the verifying. However, if you manage your own domain's DNS records with a routing setup that answers differently depending on your country, keep your exit country fixed while checking whether the record has propagated; otherwise you will see a different result on every attempt even though the record has propagated.

Which exit type fits which Bluesky job?

The exit type decision depends on whether the job carries a session and how long it runs. For work that reads public posts without signing in, stability and bandwidth are the priorities; here datacenter proxy is more than sufficient in most setups and is the lowest-cost option.

For signed-in client use the picture changes. A client carrying a session token appearing from different countries at short intervals produces an inconsistent picture and can lead to unnecessary re-verification steps. In this scenario a fixed-exit ISP proxy or a residential exit with a sticky endpoint behaves more predictably. A mobile exit makes sense when you want to reproduce cases where the app is used from a phone; because the carrier network gathers many subscribers behind the same address pool, the exit there is shared by nature and does not belong to a single user.

Long-running stream listening is a third category. Here the decisive factor is not the type of IP but whether the connection can stay up for hours. A pool that rotates frequently is not suited to this job; every rotation breaks the open tunnel, creating gaps in the stream. Instead, choose a fixed endpoint and bring address changes into play only when the connection actually drops, preferably from inside the reconnection logic.

On the cost side the ordering is equally clear: datacenter exits are the cheapest, residential and carrier exits more expensive. If the job consists of nothing more than reading public data, there is no payoff in buying an expensive exit.

Where does the proxy sit among the protocol components?

The proxy sits at the first hop between the client and the network. That is, both the write request going to the PDS and the read query going to the indexing layer appear from the same exit. The network's own server-to-server traffic, on the other hand, has nothing to do with your proxy; a post circulating across the network does not pass through your exit.

This distinction removes two common misconceptions. First, using a proxy does not change who on the network your post reaches; distribution is decided entirely on the protocol side. Second, using a proxy does not speed up the connection. On the contrary, since another hop is added in between, latency usually increases. The only exception is the rare case where the default route is circuitous and the proxy exit connects more directly to the target; this is not a rule and should not be made a reason to buy.

The same logic applies to deciding where to set things up. A rule defined in the browser affects only that browser; a desktop client or command line tool opens its own connection and does not see that rule. A system-wide setting gives the broadest scope but affects all applications. The middle ground is per-application routing at the operating system level; going through the setup screens one by one to see which tool has its own proxy field and which follows the system setting produces results far faster than hunting for the problem afterwards.

Once setup is complete, confirm that the exit really has changed with the my IP address tool. If the browser has changed but the client has not, you will see two different results and where the problem lies becomes immediately clear.