Substack Proxy Setup: Publication Address, Live Channel and Rate Limits

The first fact that defines the relationship between Substack and a proxy is this: the publication you read often does not sit on a single central domain. A publication where the author has connected their own domain reaches your browser under a completely different host name; images and attachments come from a separate distribution network, and the email copy of posts is delivered through a channel your browser never sees.

This fragmentation is felt directly during setup. If you have written an extension rule that covers only the main domain, the interface will open, but publications moved to a custom domain fall outside the scope and those requests go out from your real exit. The result is a half-routed session.

The second fact concerns what a proxy is not. A proxy changes your exit address; it does not change your subscription cookie, your browser version, your language preference or your email address. Your access to a paid publication depends on your subscription, not on the country you connect from.

How many separate addresses does a Substack publication connect to?

When you open a post, your client talks to at least three different places. The first is the host name the publication is hosted on: either the platform's subdomain or the custom domain the author has connected. The second is the session layer that carries your account and subscription status. The third is the distribution network serving cover images, embedded audio and video files; this third group generates many times the volume of the page's text.

The custom domain is the most overlooked part of this picture. If, of two publications hosted on the same platform, one has stayed on the platform subdomain while the other has moved to the author's own domain, a domain-based proxy rule covers only one of them. Setting your rule based on the entire browser profile rather than on a list of publications eliminates this problem at the root.

The email copy of posts arrives by a completely different path. When you read the newsletter that lands in your inbox, your browser proxy setting is not in play; your mail client establishes its own connection, and that connection is only routed if it is configured at the client level. The protocol-side distinction is decisive here: the mail client reads its own connection settings and the rule you defined in the browser never sees this traffic.

Where is domain name resolution performed?

If you use an HTTP proxy, the client declares the target with a CONNECT ornek.example:443 line and the proxy handles resolution. With SOCKS5 the decision belongs to the client: some clients resolve the address on their own network and give the proxy only an IP, while others leave the domain name to the proxy (socks5h). The difference becomes sharpest with custom domains, because if resolution is done on your network, which publication you are reading is visible to your local DNS server. Details: where DNS is resolved in SOCKS5.

Why is access inconsistent on corporate and school networks?

Corporate networks usually manage access with domain lists or category labels. Because some Substack publications live on custom domains, a single category rule cannot catch them all in the same way: one publication opens while another returns a connection error. Users think this is a platform fault, when it is actually a difference in listing.

The second mechanism is the server name indication in the TLS handshake. A filter can see the target host name without even opening the encrypted traffic, and can drop the connection at the handshake stage. The symptom is typical: the connection is reset before the page loads at all, and the error message comes from the network rather than the server.

The third is TLS inspection. If the corporate network opens and re-encrypts traffic with its own certificate, you will see a certificate warning in the browser. On a corporate device this may be a deliberate policy; on a network you do not know, it is a sign to stop. The distinction of the topic proxies and TLS certificate validation article.

In all three cases the proxy is not a magic key; it merely moves your exit to another point. If the corporate network also closes proxy ports, the connection cannot be established at all. If you work on your own device and your own line, SOCKS5 exit usually requires fewer rules; for general behaviour on school and workplace networks, see network blocks article is a good starting point.

Exit types for reading, archive crawling and team access

Substack work roughly divides into three profiles, and each requires a different exit. Reading posts with your own subscription is the lightest scenario: it is text-heavy, the session must stay fixed, and the volume is low. Reading publication archives at scale is the opposite: no session is needed, but the request count is high. The third is team use, where several editors manage the same publication; there, predictability of the exit comes before speed.

The most common mistake in the table is made on the last row: teams tie the exit to the person. When two editors enter the same publication from two different countries, the picture looks inconsistent. Tying the exit to the account — that is, everyone going through the same fixed address — leaves a cleaner trace. The general framework of this approach proxy for social media management page.

How many people the exit is shared with matters no less than the type. In a shared pool, the address's history also reflects on your session; the difference shared and dedicated proxies is explained in that article.

How are Chat, Notes and notifications carried on an open connection?

A message appearing instantly in an interface happens in one of two ways: either the client polls the server at short intervals, or a connection established once is kept open. On the web, the second path is usually established with WebSocket and starts like a normal HTTPS request, turning into a persistent channel with the Upgrade header.

The critical distinction from the proxy side is this: because a wss:// connection is already established inside a CONNECT tunnel, the proxy does not see the upgrade inside the tunnel and no problem arises. On a plain ws:// connection, however, the proxy must understand the upgrade header; an old or restrictively configured proxy may reject it. The mechanism is explained step by step in the WebSocket and proxy article.

The second risk is the idle timeout. A channel that stays open may carry no data for minutes; if an intermediate proxy treats it as a dead connection and closes it, the interface silently stops updating. The symptom is not an error message but the feeling that "no new messages are coming". Refreshing the page fixes it temporarily. For connection lifetime settings keep-alive and connection pooling article.

The third is rotation. An exit that changes address on every request rotating proxy is incompatible with a long-lived channel; the open socket drops at the first rotation. In scenarios that use a live channel a sticky session is essential; its setup in the sticky session guide.

• If you are going to use a live channel, choose a sticky duration longer than your working time.
• The mobile app's instant notifications come through the operating system's push channel and do not use your Wi-Fi proxy setting.
• To tell when the channel has dropped, leave the network tab of the browser developer tools open.