Using a Proxy with Lemmy: The Server Stack, Moderation and Sessions
Lemmy is a community-oriented link-sharing network and works through federation. This page explains how a post moves between local and remote servers, where moderation decisions are technically written, how notifications are received, and where the proxy fits into this picture.
Stack viewThe separation of the interface, the application interface and the federation layer.
02
ModerationThe technical equivalent of removal, deletion and server-level restrictions.
03
NotificationThe effect of polling rather than a persistent connection on request volume.
04
SessionToken-based identity, two-step verification and location change.
Lemmy is a link-sharing network where posts are gathered under communities and ranked by voting. Its architecture is built on ActivityPub: each server keeps its own database and synchronises copies of content by exchanging messages with remote servers. As a user, you always talk to your own server.
This structure splits the proxy decision into two separate questions. The first is where the traffic leaving your client goes; the second is where the federation traffic between servers passes. The second has nothing to do with the user's proxy setting, and not knowing this distinction leads to needless expectations.
Below we first break the stack into its layers, then move on to the notification mechanism, moderation visibility, account security and setup.
Which layers does Lemmy traffic pass through?
The interface you see in the browser is a client application downloaded from the server. This application takes content not directly from the database but from the server's application programming interface; the calls go to versioned paths under /api/ and return JSON. Third-party mobile clients use the same paths, they just draw the interface themselves.
One layer down is the server process. It verifies the credentials of the incoming request, writes to the database and, if necessary, queues the federation job. The bottom layer is the federation layer that carries out server-to-server messaging; here the conversation is not with your client but between two servers.
A proxy covers only the top two layers: the connection going from your browser or client to the server. The connection your server establishes with remote servers does not use your exit. So if you cannot reach a remote community and the problem is on the federation side, changing the proxy will not change the outcome; the solution lies with the server administrator.
In practice the distinction is checked like this: if you cannot see the same content through your own server but can see it through another server's web interface, the issue is not your network access but the federation state. Conversely, if neither server opens, the issue is on your network and checking the liveness of the endpoint with proxy checker tool is the first step.
DIAGRAMThe layers from the client to the database
You can scroll the diagram horizontally to inspect it
The proxy rule covers only the top two layers; the federation layer below uses the server's own network connection.
How do notifications arrive: a persistent channel or polling?
Early versions of Lemmy offered the client a persistent WebSocket channel; the interface received new comments and votes through that channel in real time. The project later removed this interface and directed clients to versioned HTTP calls. In today's common setup, the interface runs a polling loop that asks for the unread notification count at regular intervals.
This change has two consequences on the proxy side. The first is positive: since there is no persistent connection, the problem of the tunnel hitting an idle timeout disappears. In a tab left open for a long time, you do not expect the connection to drop silently and notifications to stop.
The second requires attention: polling means separate requests repeated at regular intervals. A large number of tabs or clients left open for a long time generate continuous requests from a single exit address. Per-address thresholds on the server side can notice this build-up. If you keep several sessions open at once, closing the ones you are not using eases the load on both the server and your own connection pool.
Connection reuse helps here. If polling requests can be reused over the same connection, you do not pay the cost of a new handshake every time. How this behaviour is preserved on the proxy side is keep-alive and connection pooling is explained in that article.
Tip
If you are writing your own tool, keep the polling interval fixed and reasonable, read the limit information in the response headers, and widen the interval temporarily when you get an error. For the general rules of automated jobs, see proxy for automation and bots page for more details.
What do moderation decisions and regional visibility mean technically?
On Lemmy there are two different actions on content, and they are often confused. The removal action performed by a community moderator or a server administrator makes the content invisible on the local server. The deletion action performed by the person who wrote the content withdraws the record by its owner. Both are notified to remote servers through federation, but whether the remote server applies that notification depends on its own configuration.
The conclusion that follows is important: a post may not be visible on your server but may still be present on another server. This is not a bug but a natural consequence of federation. A proxy does not change this picture; connecting from a different exit does not remove a local moderation decision, because the decision was applied to the content, not to your address.
There are restrictions at server level too. A server can cut off federation with another server entirely, or be configured to talk only to certain servers. These choices are administrative decisions and cannot be changed from outside. If you want to reach a community but your own server does not talk to that server, the right route is to open an account on the server in question or to contact the administrator.
Regional visibility is a third topic, and it is usually the network's decision rather than the platform's: in some countries, access to certain domains can be restricted at provider level. In that case what you see is not a moderation decision but a network access problem; to tell the two apart, it is enough to try the same address from a different network.
How does a post move between local and remote servers?
When you create a post, the record is first written to your own server's database. This step is entirely local and is triggered by a request coming from your exit address. Your server then sends a federation message to the remote servers that follow this post; this message goes from server to server.
When the remote server receives the message, it creates its own copy. There are now two records: the original record on your server and the copy on the remote server. A local moderation decision is applied to the original record and notified to the copy; the remote server's own moderation decision affects only its own copy.
Understanding this two-lane structure makes troubleshooting easier. If your post is visible on your own server but not in the remote community, the problem is in federation delivery; it may be a delay, a queue build-up or an outage between servers. If it is not visible even on your own server, the problem is on the request side and may be related to your proxy configuration.
Remembering that federation delivery has nothing to do with your proxy prevents wasted attempts. You cannot fix a federation delay by changing the exit.
DIAGRAMA post's journey on the local and remote server
You can scroll the diagram horizontally to inspect it
Half of the steps take place on your server and half on the remote server; the steps on the remote side do not use your exit address.
Which factor carries how much weight in the exit decision?
The factors that determine exit selection for Lemmy use differ from those on image-heavy platforms. Most of the traffic is text; large media transfer is relatively rare. So stability and consistency matter more than bandwidth.
The highest weight lies with session stability. An address change on a session carrying a token creates needless friction. Right after that comes the consistency of the exit country: connection latency and regional access behaviour can vary depending on the region your server is hosted in. Third comes the concurrent connection allowance; many polling tabs accumulate on a single address. The lowest weight lies with the need for rotation: in signed-in use, rotation is not an advantage but a source of problems.
This ranking directly determines the product choice. If stability is the priority, ISP proxy or a residential exit with a static endpoint is suitable. If you are running a research job that only reads publicly accessible posts and does not sign in, datacenter proxy is more economical and sufficient. When rotation makes sense is the difference between rotating and static proxies goes into detail on the topic.
On the protocol side the choice depends on the client. If you use a browser, an HTTP proxy is sufficient; if you use a desktop or command-line tool, SOCKS5 offers broader compatibility.
DIAGRAMThe weights of the factors in the exit decision for Lemmy use
You can scroll the diagram horizontally to inspect it
The values in the bars are not measurements but scores on a /100 scale showing the weight of the factors relative to one another.
Determine the exit that suits your Lemmy use
A static endpoint takes priority in signed-in use; in read jobs without sign-in a datacenter solution is sufficient.
Choose whichever you need from our residential proxies, datacenter proxies, IPv6 and ISP solutions. Every plan comes with unlimited options, 99.9% uptime, rotating proxies, sticky sessions and 24/7 support. Ideal for web scraping, ad verification, SEO monitoring and digital data collection.
ISP ProxyStatic Turkish IPs registered to an ISP
ISP-registered static Türkiye IPs; they combine datacenter speed with the reputation of a real carrier. Ideal for long sessions and low-ping use.
Lemmy sessions are token-based. When you sign in, the server generates a token and the client carries it in subsequent requests. Because the token is stored on the client, someone with access to your device can use the session without knowing your password. So make signing out a habit on shared computers.
The invalidation of tokens by a password change is the single most effective step in account security. When you see something suspicious, change the password first; that way any sessions left open are dropped. Two-step verification is also supported: it is set up with an app that generates time-based one-time codes and asks for an extra field during sign-in. This layer works independently of your exit address, so using a proxy does not affect the setup.
On the location change side, Lemmy is not as aggressive as the large centralised platforms; however, server administrators can apply their own registration and security rules. Even so, the right habit is the same: use a single, static exit per account, maintain country consistency, and do not change the exit unless it is really necessary.
Warning
This page was not written for creating large numbers of accounts, artificially influencing voting or stepping outside community rules. Lemmy communities are run by volunteer moderators and each server's own rules are binding.
Setup and verification steps
Where you set the proxy up determines its scope. If you will only be working in the browser, a separate profile is the cleanest method. If you use a desktop client, check whether the application has its own proxy field; if not, a system setting or process-based routing is required. On the browser side this field is usually in the network section of the settings, and on desktop Linux in the system network settings or shell environment variables; if both are defined at once, you need to know which one the tool reads.
Step
What to do
Verification
1
Define the endpoint, port and credentials
Is the connection being established?
2
Choose the scope: profile, system or process
Do the client and the browser show the same address?
Once the five steps are complete, the setup is sound. After that it is a matter of usage discipline: staying on the same exit for the same account, closing unnecessary tabs, and eliminating the layers one by one when a problem arises.
When the setup is done, also observe the polling behaviour: leave a tab open and see how often the unread count is updated. Knowing how many tabs you run from the same exit is the first place to look when you hit per-address thresholds. A certain increase in latency is also an expected result; because the traffic goes first to the proxy and from there to the target, the route is split into two legs and the time you measure is the sum of those two legs.
Common situations and how to read them correctly
Status
The correct reading
A remote community appears empty
Federation state; changing the proxy has no effect
The post exists locally but not remotely
There may be a delay in the delivery queue
The page does not open at all
A network access or endpoint problem; test liveness
The notification count is not updating
Polling may have stopped; refresh the tab
407 response
Credentials or address authorisation are missing
The session drops unexpectedly
The token may have been invalidated or the password changed
The first two rows of the table point to the most common misdiagnosis specific to Lemmy: mistaking a gap caused by federation for a network problem. The fastest way to tell them apart is to check the same content through another server's web interface.
The remaining rows are general proxy behaviours that apply on other platforms as well. Authentication errors fall into two kinds: a username and password never entered into the client, or an exit address not authorised in the panel. The consequence of protocol choice unfolds more quietly; when the wrong protocol is defined, the connection appears to be established but the client never receives the response it expects.
Things a proxy does not solve
Setting the right expectation is more valuable than mistaking the wrong tool for the right one. A proxy does not shorten federation delay; server-to-server delivery does not pass through your exit. A proxy does not change the fact that one server has cut off federation with another; that is an administrative decision. A proxy does not bring back a post removed by a community moderator.
Nor does a proxy speed up your connection. Because a stop is added along the way, latency rises in most setups; this is an expected and accepted price. The rare cases where the default route is unusually circuitous are the exception and are not a reason to buy.
What a proxy really provides is fixing the exit point to an address you have chosen and defined. In return you get access discipline in corporate environments, load distribution in research jobs and comparable results in regional verification. For a broader framework, the proxy vs VPN differences article compares the scope of the two tools.
Questions about using a proxy with Lemmy
01A remote community appears empty — will changing the proxy fix it?
No. Remote content arriving depends on federation delivery, and that traffic passes between servers; it does not use your exit address. If you can see the same content through another server's web interface, the problem is on the federation side and its solution lies with the server administrator.
02Does the Lemmy interface show notifications in real time?
In a common setup, the interface uses a polling loop that asks for the unread count at regular intervals. Since there is no persistent channel, the tunnel hitting an idle timeout is not an issue; on the other hand, many tabs left open for a long time generate continuous requests from a single address.
03Does two-step verification work together with a proxy?
Yes. A time-based code is generated on your own device and has nothing to do with your exit address. Using a proxy does not change the setup or the sign-in flow. In a suspicious situation, changing the password is the fastest measure because it drops open sessions.
04Can I see a removed post from a different exit?
A local moderation decision is applied to the content, not to your address; changing the exit does not affect it. A copy of the same content may still be present on another server, but this is a natural consequence of federation and does not invalidate the decision.
05Which protocol should I choose?
If you work in the browser, an HTTP proxy is sufficient and is the simplest to set up. If a desktop client, a command-line tool or a script you have written yourself is involved, SOCKS5 offers broader compatibility and gives you the option of leaving name resolution to the remote side.
06Can I read publicly accessible posts with my own tool?
It is technically possible as long as you comply with the server's rules and the crawler access directive, if there is one. Keep the polling interval reasonable, read the limit information in the responses, and back off when you get an error. On federated networks the infrastructure cost is covered by volunteers; going slow is a courtesy before it is an obligation.
07Is a free proxy enough for this job?
It can be used to try out the concept, but it is not recommended for use involving sign-in. Free proxy endpoints are short-lived, it is unknown who operates them and they drop frequently. In a session carrying a token, a drop means signing in again and a new address.