Medium Proxy: Bandwidth, Leaks and Session Security
Medium is a platform that looks plain on the reading side but uses the network constantly on the writing side: drafts save themselves and separate requests open while images upload. This page covers the transfer load, the leak checks and how account security behaves when your location changes.
Transfer breakdownWhere data is spent in the reading and writing directions.
02
Upload directionHow draft saving and image uploading behave over the proxy.
03
Leak checkWhat DNS and WebRTC tests reveal on this platform.
04
Session securityTwo-step verification and the consequences of an abrupt location change.
If you use Medium only for reading, setting up a proxy is a simple matter of scope. If you use it to write, publish or help run a publication, the picture changes: part of the traffic now flows from you to the server, and the upstream capacity of your connection becomes decisive.
The second distinction is on the account side. When the sign-in flow runs through an e-mail link or an identity provider, a step outside the proxy's scope comes into play: your e-mail client, or the identity provider's session, may not be subject to your proxy rule. This explains why the setup sometimes works only halfway.
The sections below cover, in order, page structure, the transfer breakdown, the upload direction, exit type matching, leak checks and session security. The final sections are devoted to setup, a symptom table and measurement discipline.
What does a Medium page look like on the network side?
On the reading side the skeleton is plain: the text body, a few scripts and fonts. The real volume comes from images. Cover images and in-body pictures are served from a separate image delivery path and are requested at different sizes depending on the client's screen width. If your proxy rule targets only the main domain, the article opens but the images do not; this is a classic scope problem.
The second characteristic is custom domains. Some publications are served over their own domains, while the infrastructure remains the same. If you have written a domain-based rule list, those pages may fall outside your list and the traffic goes out directly. The only way to catch such silent leaks is to choose a wide scope instead of keeping the rule narrow, or to verify results regularly.
Embedded content is a separate layer
Elements embedded in articles — videos, code snippets, tweet cards or maps — load entirely from other domains. Unless they appear in your rule list, they bypass the proxy. This matters if you are verifying a regional view: an embedded element behaves according to its own geographic rules and can produce a different result from the rest of the page.
Member-only content metering also generates additional requests on the network side. The calls that determine the state of your reading allowance are evaluated together with the session; for that reason, keeping the exit address fixed in a signed-in session matters more than it does for signed-out reading. The general framework for session-based scenarios proxy for social media management page.
Where data goes in the reading direction
Moving to a residential or mobile plan without a transfer plan means paying the bill without understanding where the quota goes. On Medium the breakdown is relatively predictable: text and interface take a small share, images take a noticeably larger share, and embedded and external media vary a great deal from page to page. A technical article may have no embedded elements at all; in a video review they can become the heaviest item.
The practical consequence of this breakdown is simple: a read-only workload does not need a data-metered plan. In scenarios that read open articles and require no sign-in, datacenter exit is more than enough; what matters here is not the network the exit belongs to, but whether the rule also covers the image path. The data cost is only worth taking on when you are signed in and the type of exit genuinely matters.
There are concrete ways to shrink the quota. Browser settings that defer image loading, switching the page to reading mode and blocking embedded elements reduce transfer noticeably. To see the scale of this in your own usage, track your transfer through the panel for a month; the calculation method is in the bandwidth calculation article.
On the latency side you need to set expectations correctly from the start. A proxy adds an extra hop to the connection; the first byte of the page therefore takes longer to arrive in most setups, and a proxy does not lower the ping value. On text-heavy pages this difference does not spoil the reading experience, but it should not be ignored when you measure (what proxy latency is).
DIAGRAMSub-shares of the total load in the reading direction
You can scroll the diagram horizontally to inspect it
The stages represent sub-shares of the total page load; the numbers are relative weights, not measurements.
The writing direction: draft saving and image uploading
While the article editor is open, the client sends save requests to the server at regular intervals. These requests are small but continuous; over a long writing session their number builds up quickly. On a plan with a low concurrent connection ceiling, or on a high-latency exit, this can lead to "not saved" warnings. The fix is usually not to change the exit but to pick a more stable endpoint.
Image uploading is a different load profile. Most home connections are asymmetric: download capacity is noticeably higher than upload capacity. If you use a residential or mobile exit, that asymmetry doubles, because both your line and the exit line carry the same limit. If you are going to upload large cover images, an exit with datacenter-grade stability such as an ISP proxy behaves more predictably.
The third point is timeouts. An upload request opens as a single long-lived connection; if that connection hits a timeout rule on the proxy side, the upload is cut off halfway and the client starts over. Knowing your provider's timeout and concurrent connection policy prevents this cycle from the outset (concurrent connection limit).
Tip
If you are going to edit a long article over a proxy, finish the text in a local file first, then transfer it in one go. That way you both reduce the number of continuous save requests and avoid losing your work if the connection drops.
Matching exit type to job type
The heat table below summarises the relative suitability of three exit families for the five types of work described on this page. The values are not measurement results but a quantified version of the preference ranking argued for in the text; in your own usage the outcome will vary with plan details.
The general tendency is this: for reading open content and for compliant, scaled reading, datacenter exits stand out, because speed and cost are what matter in that work. For tasks that demand upstream capacity, such as drafting articles and uploading images, static ISP exits behave more stably. Regional view verification, meanwhile, shifts towards residential proxies when it requires a profile close to real subscriber lines.
This matching is not absolute; two variables can change the outcome. The first is how many people the exit is shared with — a shared address behaves differently from a dedicated address in the same class. The second is location distance; if the exit is far from both you and the target, the table flips and the option that looks most suitable turns out to be the slowest in practice. For comparison the difference between residential and datacenter article.
When you decide, ask a third question as well: how long will this work last? An expensive pool is unnecessary for a one-off verification. For running a publication over many months, however, being able to keep the exit you chose on day one fixed is far more valuable than the speed difference on that first day.
DIAGRAMRelative suitability of exit family and type of work
You can scroll the diagram horizontally to inspect it
The values are relative weights out of 100 and summarise the reasoning in the text; they are not measurement results or a performance guarantee.
Choose a plan based on how you use Medium
For read-only work a datacenter exit is enough; in sessions that write articles and upload images an ISP exit behaves more stably.
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.
The idea of a leak stays abstract until you make it concrete, so let us do that. A DNS leak means your browser resolves the domain with your own network's DNS server rather than through the proxy. Even if the connection itself goes over the proxy, which domains you query remains visible to your internet service provider. On a platform like Medium, which is also served over custom domains, that means which publications you read appear in the query logs.
A WebRTC leak is a different channel. The WebRTC interface in the browser can report your local network address, and in some cases your real public address, to a page entirely independently of the proxy setting. This causes the page to see you directly rather than behind the proxy. Run both tests as soon as the setup is finished: the DNS leak test and the WebRTC leak test.
The third channel is IPv6, and it is the quietest because it produces no error message at all: the page opens, the article loads, and only some of the requests go out from your real address. On publications with custom domains the risk grows further; if an independent domain publishes its own IPv6 record, a setup that relies on an IPv4 exit never engages on that publication, and the domain showing in your rule list lulls you into false confidence. The fix is an IPv6-capable exit or to disable IPv6 in the test profile.
The fourth is the proxy's own headers. X-Forwarded-For or Via An exit that adds them tells the target that the request came from an intermediate server. You can see this anonymity test with; the conceptual background is in anonymity levels the article. The liveness of the exit you verify with the proxy checker tool with.
Two-step verification and sudden location changes
Signing in is a special moment from the proxy's point of view, because one link in the chain can fall outside your rule. If you sign in via an e-mail link, the client where you click the link — often an e-mail application or another browser — may not be within the proxy scope. The result: the sign-in request comes from one address and the opening of the link from another.
The same applies to signing in through an identity provider. If the provider's session is already open in your browser, the address used during the redirect may not be the one from your proxied profile. The simplest way to avoid such confusion is to complete the entire sign-in flow in a single profile and over a single exit.
If two-factor authentication is enabled, the order of setup matters. If the application generating the verification code needs no internet connection, the proxy has nothing to do with it; if the code arrives by SMS or e-mail, that channel raises a separate scope question. From a security standpoint the correct order is this: set up two-factor authentication and store your backup codes securely first, then change your exit.
Caution
Never enter your credentials over a proxy whose source you do not know. Even if your traffic is encrypted, an exit that shows a certificate warning may be opening and re-establishing the TLS session. If you see such a warning, stop and change the exit (TLS certificate validation).
Making the location change gradually also helps. If your account has been used from a single country for months and you suddenly connect from another continent, being asked for additional verification is an expected outcome — it is not a fault but a security feature. If you are planning a long-term change, choose the exit once and keep it fixed (is it safe to use a proxy).
Setup and protocol notes
Protocol choice is not critical on this platform; Medium is a web application running over classic HTTPS, and for browser work an HTTP proxy and SOCKS5 give the same result. The difference appears when you step outside the browser: if you are going to use a command line tool or a desktop client, SOCKS5 support is generally broader. The comparison is in the HTTP vs SOCKS5 difference article.
Where the rule is written, however, is critical. A narrow rule based on a domain list leaves out publications on custom domains and embedded content. A system-wide setting solves that problem but affects every task on the machine. The middle ground is a browser profile dedicated solely to this work: the scope is predictable and the side effects are limited. The table below reads this decision directly through the writing workflow — the same option produces different outcomes for draft saving and for image uploading.
Setup point
Effect on draft saving
Effect on image uploading
System-wide setting
Every request, including save requests, goes out over the same exit, leaving no scope gap
The upload shares the same line as all other traffic on the machine
A browser profile dedicated to this work
The editor stays within a single scope and does not get mixed up with other sessions
Goes out from the same profile; easy to measure and repeat
Per-application routing
Only the process you select is covered; background services stay outside
For large files you can dedicate the capacity to a single process
Domain list or PAC rule
If the save endpoint is not on the list, the request silently falls outside the rule
If the image delivery path is not on the list, the upload goes out directly
Whichever point you choose, the fields you fill in stay the same: endpoint name, port and credentials. You get these from your customer panel and define them before opening the editor. If you cannot tell which port corresponds to which endpoint, the proxy port numbers article shows the mapping. On the team side there is one caveat: two people sharing the same access credentials cannot tell which session caused the problem when an upload fails halfway — requesting separate credentials per person for writing work removes that uncertainty from the start.
Symptom table and first responses
Observation
Root cause
First response
The article opens, the images do not
The image delivery path is outside the rule
Widen the rule or switch to a system-wide setting
Publications on custom domains open without the proxy
The domain list was written too narrowly
Use profile-based scope instead of a list
The draft shows a "not saved" warning
High latency or a connection ceiling
Choose a more stable exit and reduce the number of open tabs
Image uploads are cut off halfway
Timeout or low upstream capacity
Try an ISP exit, shrink the image and upload again
The sign-in link opens from a different address
The e-mail client is outside the proxy scope
Complete the sign-in flow in a single profile
An embedded video shows a different region
The embedded element loads from its own domain
Keep the scope wide and run the test in a clean profile
The reading allowance counter looks wrong
The session request went out over a different exit
Repeat the sign-in flow in a single profile
Half the items in the table come down to a single root cause: a mismatch between the scope of the rule and the expectation. When one request is inside the rule and its neighbour is outside, the result looks inconsistent and people start looking for the problem on the platform. Always starting the diagnosis with the scope question breaks that cycle.
The other half relates to capacity. Upload interruptions, save warnings and requests that stop halfway usually come down to the exit's bandwidth or the provider's timeout policy. With problems like these, reading your plan's limits before changing the exit saves time (uptime and SLA).
Measure an exit before putting it to work
Choosing an exit is often treated as a one-off decision, when in fact it is a decision made without measurement. A simple discipline eliminates most problems up front: measure the same exit several times at different hours of the day, run all four verification tests, and confirm that the sticky window really covers the length of your work. The summary below shows these three measures.
Repeated measurement matters because the peak-hour effect in shared pools is real. A single measurement taken in the morning does not represent behaviour in the evening. Measure with a ping test and note the results; when you are deciding between two exits, you will have comparable data at hand.
Verification tests, meanwhile, are not a one-off: they should be repeated after every configuration change. A browser update, a new extension or a profile change can silently alter the scope. The checklist is short: exit address, DNS resolution, WebRTC and added headers.
Repeat the measurement at a minimum of three different hours and write down the results.
Re-run all four verification tests after every configuration change.
Choose a sticky window wider than the working time you have planned.
Track your monthly transfer in the panel; image-heavy reading grows the quota quickly.
If you work in a team, record which account is on which exit in a single place.
Finally, set your expectations correctly: a proxy is not an accelerator, it is a routing decision. If you are reading normally from your own country, you do not need this layer. For the difference in scope and encryption see proxy vs VPN, and for the limits of free options see the free proxy page.
DIAGRAMThe three measures before putting an exit to work
You can scroll the diagram horizontally to inspect it
The numbers on the cards indicate the recommended minimum practice; they are setup discipline, not a performance promise.
Questions about Medium and proxies
01The article opens but the images do not load — what should I do?
Images are not served from the main domain but from a separate image delivery path. A narrow rule based on a domain list leaves those requests out. Widen the rule, or use a system-wide scope in a browser profile dedicated solely to this task.
02Why does the connection drop while I am uploading an image?
The upload opens as a single long-lived connection and can hit a timeout rule on the proxy side. The second possibility is upstream capacity: home lines are asymmetric, and a residential exit doubles that limit. A stable ISP exit behaves more predictably for this kind of work.
03Why does my session open from a different address when I click the sign-in link?
When you sign in via an e-mail link, the client that opens the link — your e-mail application or another browser — may fall outside your proxy scope. Completing the entire sign-in flow in a single profile and over a single exit prevents this confusion.
04Should I enable two-factor authentication before setting up the proxy?
Yes. The correct order is to set up two-factor authentication and store your backup codes securely first, then change your exit. Being asked for additional verification after a location change is expected behaviour, and being prepared makes the process easier.
05Which test should I use to check for DNS leaks, and how often?
Run the DNS leak test once right after setup, then again after every event that changes the scope: a browser update, a new extension, a profile change, a provider endpoint change. Run the test with the proxy on and off, back to back; the meaning lies not in a single list but in the difference between the two. If the result does not change, resolution is happening on your own network.
06Why does an embedded video show a different region?
Embedded elements load from their own domains and behave according to their own geographic rules. If your rule list does not cover those domains, the element bypasses the proxy. If you are doing regional verification, keep the scope wide and repeat the test in a clean profile.
07Which exit is enough for reading only?
What matters for reading is not the type of exit but the scope of the rule: with a setup that covers the image delivery path and publications on custom domains, you can read open articles over a datacenter exit. If the scope is incomplete, even the most expensive pool gives you the same half result. Move to a data-metered plan only in scenarios where you are signed in and the network the exit belongs to genuinely matters.
08Why does draft autosave lag over the proxy?
The editor sends small but frequent save requests; every round trip now goes through the proxy, and latency is multiplied by that count. If you are running close to the concurrent connection ceiling, the save request queues and a "not saved" warning appears. First reduce the number of tabs, then try a more stable endpoint; for long articles, finishing the text locally and transferring it in one go removes this cycle entirely.