The records worth keeping once you run more than three proxy lines
There’s a specific moment that happens to everyone who scales past a handful of lines. Something breaks on one account, you go to check which exit it was using, and you realize you genuinely don’t know. Maybe it was the line you swapped in last month. Maybe it was the one you rotated after a carrier issue. You’re now doing archaeology on your own infrastructure, and the answer matters because the account is the thing at risk, not the modem.
I run mobile proxy hardware out of Singapore, real SingTel, M1, and StarHub SIMs sitting in physical modems. I’ve been through the version of this where the records lived in my head and a couple of text files, and I’ve been through the rebuild after that stopped working. This is the list of things I actually wish I’d been writing down from line one, and the reasoning behind each of them.
Why three lines is where it breaks
Three is roughly where it breaks, and there’s a reason for that number. With one or two lines you hold the whole state in your head without trying. At three you can still reconstruct it from memory if you sit down and think. Past that, the number of relationships between lines, accounts, sessions, and incidents grows faster than your recall does, and the first time you’re wrong about one of those relationships it costs you an account rather than an afternoon.
The line inventory
The foundation record is the line inventory: one row per physical line. What goes in it is an internal identifier you assign, the carrier, the plan, the modem it lives in and which slot, the local port it’s exposed on, the date it went into service, and its current status. The discipline is that a line exists in this file the day it arrives, before it’s ever used for anything, so there’s never a line running that isn’t written down somewhere.
The internal identifier deserves a moment because people get it wrong in a way that hurts later. Don’t name lines after the port number, the IP, or the account currently using them, because all three of those change. Give each physical line a stable, arbitrary label that never changes for the life of that SIM, and let everything else be an attribute that can move. When a line is retired, that label retires with it and never gets reused, so an old log entry always means what it says.
Assignment, and why the history matters more than the state
The second record is assignment: which line is serving which account or profile right now. This is the one people keep entirely in their head, and it’s the one that costs the most when it’s wrong. Every entry needs the line label, the thing using it, and the date the assignment started. If you’re running sticky sessions, this is also where you note the session identifier holding the profile to that exit.
But the current assignment isn’t enough on its own, and this is the part that separates records that help from records that just describe. You need the history, not just the state. When an account gets a challenge, the useful question is almost never what exit is it on now, it’s what exits has it ever been on and when did each of those changes happen. If you overwrite the assignment row every time you rotate, you’ve thrown away exactly the data you’ll want.
So keep an events log alongside it: an append-only file where every meaningful thing that happens to a line or an assignment gets a row. Assigned, unassigned, IP changed, modem rebooted, line went down, line came back, plan renewed, SIM replaced. Timestamped, in one time zone, written the moment it happens rather than reconstructed later.
That timestamping discipline pays off somewhere people don’t anticipate: talking to a carrier or a provider about a problem. The difference between “this line has been flaky” and “this line dropped at these eleven timestamps over four days, each time for between forty seconds and three minutes” is the difference between being told to reboot it and getting an actual answer. Records turn a complaint into a report.
What belongs on the account side
On the account side, keep a record of what each profile actually is: what it’s for, roughly when it was created, what identity characteristics it’s meant to present, what time zone and locale it runs with, and which line it’s tied to. You’re not trying to build a full profile manager here. You’re trying to make sure that when you have to move a profile to a new exit, you know what the new exit needs to look like for that move to be uneventful.
One firm boundary though: credentials do not live in the same place as your operational records. The inventory tells you which line serves which account. It does not hold the password, the session cookie, or the two-factor seed for that account. Those belong in a password manager or a secrets store with different access rules, because the inventory is a file you’ll open constantly, share with a contractor, and eventually copy somewhere convenient.
Bandwidth, plans, and hardware
Bandwidth records are next and they’re worth more than people think. Track usage per line per billing period, not just in aggregate. The aggregate number tells you what you’re spending. The per-line number tells you which workload is actually consuming it, catches a job that’s gone into a loop, and gives you the baseline you need to notice that a line is suddenly doing three times its usual volume, which is often the first sign something is misconfigured.
Then the plan and carrier record, which is the boring one that quietly costs money. Per line: what plan it’s on, what it costs, what the data allowance is, when it renews, and how it’s paid. The failure mode here isn’t dramatic, it’s a line that lapsed because the payment method on it expired, and you found out because a client’s job started failing at three in the morning.
Hardware is its own record. Modem model, firmware version, which physical rack position or hub port it sits on, and when it was last power cycled. Firmware matters more than people expect, because behavior differences between versions are real, and when one modem in a batch of identical modems behaves differently, the first useful question is whether it’s actually running the same firmware as the others.
The record that actually predicts trouble
The most valuable record, though, is failure history per line. Every time a line does something bad, log it against the line: dropped a session, wouldn’t reconnect, got an IP from a range that immediately drew challenges, needed a manual reboot. Over a few months this file tells you something no amount of live monitoring will, which is that lines are not interchangeable. Some of them are simply worse than others, and the pattern only shows up in accumulated history.
That’s actually the argument for keeping all of this. Live monitoring tells you the state of things right now. Records tell you about trends, and almost every decision that matters in running a fleet is a trend decision: which lines to retire, which carrier is worth expanding on, whether that problem last week was a one-off or the fourth time this quarter. You can’t answer any of those from a dashboard showing current status.
Where to actually put it
I’d push back against the instinct to build something. A spreadsheet is completely adequate up to a few dozen lines, and it has the enormous advantage that you’ll actually use it. The failure mode of building a proper system on day one is that you spend a weekend on the tool and then don’t maintain the data, which is strictly worse than a messy spreadsheet you update.
The signal to move to something real is when you start needing to query across records rather than read them. When the question is “which lines on this carrier have had more than two incidents in the last thirty days and are currently assigned,” a spreadsheet stops being the right shape. At that point a small database, even a single SQLite file with the same tables you already had, is the natural step, and the migration is easy because your structure was already right.
Whatever you use, write the conventions down next to the data: what the status values mean, what time zone the timestamps are in, what each field is for. You won’t remember in six months, and if anyone else ever touches this, the conventions are the difference between records they can use and records they’ll quietly replace.
Reconcile, retire, and keep the history
The habit that makes the whole thing work is a periodic reconcile. Once a month, walk the actual state of the fleet against the records and fix the drift. Which ports are actually live, what IP is each line actually holding, does each assignment in the file match what’s really configured. It takes half an hour and it catches the thing you changed in a hurry and meant to write down.
When a line dies or a SIM gets replaced, close it out properly rather than editing over it. Mark the old label retired with a date and a reason, create a new label for the replacement, and keep the old rows. The history of a line that failed is the most useful thing you own when you’re deciding whether to buy more of that hardware or stay on that carrier.
Pulling it together
One row per physical line with a stable label that never gets reused. A current assignment record, plus an append-only history of every assignment change. An events log with real timestamps. Per-line bandwidth and per-line failure history, because those two are what reveal patterns. Plan renewal dates so nothing lapses. Hardware and firmware so you can tell identical things apart. Credentials somewhere else entirely. A spreadsheet until querying gets awkward, then a small database with the same shape. And a monthly reconcile so the records stay true.
One thing worth adding about sharing these records, since it comes up the moment you’re not the only person touching the fleet: the inventory and the assignment file are exactly what a contractor needs to do useful work, and exactly what you don’t want floating around indefinitely. Keep them somewhere with real access control rather than a shared drive folder, and keep a note of who has access and since when. That note is itself a record, and it’s the one you’ll want if you ever have to work out how something leaked.
There’s also a version of all this if you’re buying proxies rather than running the hardware. You don’t control the modem or the SIM, but you still control the assignment, the events log, the bandwidth per endpoint, and the failure history. In some ways it matters more, because when a provider’s exit starts behaving badly you have no visibility into why, and your own accumulated record of which endpoints have caused you trouble is the only evidence you’ll have when deciding whether to stay with them.
A small point about what not to record, since more isn’t automatically better. Don’t log the actual traffic, don’t keep target URLs in the same file as your account mapping, and don’t accumulate anything you’d be uncomfortable handing to someone else. Records exist to help you make decisions about infrastructure. The moment they start being a detailed history of what each account did, they’ve become a liability rather than an asset, and the useful operational value was never in that detail anyway.
If you want lines worth keeping records on in the first place, we run real SG mobile IPs out of physical hardware, with sticky sessions that hold a profile to one exit instead of rotating out from under it, and DNS that routes through the tunnel so your resolver isn’t quietly telling a different story than your exit is. Take a look at what we run.
Get new guides and videos first — join the Telegram channel.