Before You Say Just My Socks Is Slow, Check These Three Things

Han Zhe — Mon, 26 Oct 2026 09:38:05 +0000

Most "this service got slow" complaints I see follow the same pattern: someone speed-tests once, at 9pm, on whatever node the client happened to pick, and concludes the whole service went downhill. Sometimes it did get worse. More often, one of three fixable things is going on — and all three take under five minutes to check.

1. You're probably on the wrong node

A Just My Socks subscription ships with several Los Angeles nodes, and they are not equal. The s1/s2 nodes run on ordinary international routing. The s3/s4 nodes use the optimized CN2 GIA / 9929 routes back to China, which is the entire reason most people buy this service instead of a random VPS.

Clients don't always pick s3/s4 by default, and after a subscription refresh some people silently land back on s1. During the evening peak in China (roughly 8–11pm), the gap between the two groups is not subtle: the optimized lines hold up, the regular ones sag. Before judging the service, open your client, look at which node is actually selected, and switch to s3 or s4 manually. Or turn on the URL-test / auto-select group and let the client measure instead of guessing.

2. Test all three networks, not just your own

Latency from China to Los Angeles depends heavily on which carrier's route the traffic takes — China Telecom (CN2 GIA), China Unicom (9929), and China Mobile (CMI) behave like three different internets on a bad night. A node that is fine on Telecom can be miserable on Mobile, and the reverse happens too.

This is why a single ping screenshot proves almost nothing. When I want a quick health check of a subscription, I run a small open-source script I maintain, jms-speedtest. It goes through the Just My Socks data centers, tests latency and packet loss across the three carrier routes, and also checks whether the exit IP still unlocks ChatGPT, Claude, Gemini and the usual streaming services. The unlock check matters more than people think: a node can be fast and still useless to you if its IP has been flagged and every AI chat returns 403.

Packet loss is the number to watch. Latency of 160ms vs 190ms is barely noticeable in real use; 5% packet loss at peak hour absolutely is — it shows up as stalls, retries and video rebuffering that people then describe as "slow."

3. Your routing rules may be wasting the good nodes

The third cause has nothing to do with the service at all. If your Clash or sing-box setup sends everything through the proxy — including domestic sites that should go direct — you burn your monthly traffic on traffic that never needed it, and you add proxy latency to sites that were fast natively.

A maintained rule set fixes this quietly: domestic traffic direct, overseas traffic through the optimized nodes, and AI services pinned to the nodes whose IPs stay unlocked. The rule pack I use and maintain is clash-rules; it is built for Clash Verge Rev / Mihomo and auto-updates from the repository, so it is a set-once thing rather than another subscription to babysit. The setup walkthrough is in the Clash guide.

A five-minute checklist

Check which node is selected. If it is s1/s2, switch to s3/s4 and retest.
Run a three-network test and look at packet loss, not just ping.
Check the AI unlock status of your exit IP if ChatGPT or Claude is the thing failing.
Make sure domestic traffic is going direct in your rules.

If all four are fine and it is still slow at peak hour, then yes — it may be your plan tier. The LA 500 plan is shared by up to 5 devices; a household quietly running three phones, two laptops and a TV box on it will feel very different from one person on a laptop. That is a sizing problem, not a service problem, and it is cheaper to fix by upgrading (you only pay the difference) than by switching providers and starting over.

Disclosure: I maintain the justmysocks-guide project linked above. Some links in my guides are affiliate links; they do not change the prices or any of the test methodology described here.

Why Facebook Shows Your 360 Photo Flat: PhotoSphere XMP, Explained and Fixed

Han Zhe — Mon, 26 Oct 2026 06:23:59 +0000

Why Facebook Shows Your 360 Photo Flat: PhotoSphere XMP, Explained and Fixed

By Han Zhe

Your render is a perfect sphere on your own screen, and a stretched-out rug on Facebook. The pixels are not the problem. Facebook never got told the file is a sphere.

A 360 photo is an ordinary JPEG with one extra piece of information tucked into its header: a block of PhotoSphere XMP metadata that says "wrap this image around a sphere." If that block is missing — and renders from Blender, AI generators, and Photoshop exports routinely ship without it — Facebook treats the upload as a flat picture. The fix is not re-rendering anything. It is putting the missing tags back in and uploading the file again as a JPEG.

How does Facebook decide a photo is 360?

Facebook does not guess from the shape of the image. A wide rectangle could be a panorama, a banner, or a cropped screenshot; width alone proves nothing. When a JPEG arrives, Facebook reads the XMP packet stored in the JPEG's APP1 header segment and looks for the Google PhotoSphere namespace, GPano. Two fields do most of the work: GPano:ProjectionType must read equirectangular, and GPano:UsePanoramaViewer must read True. When both are present, the viewer wraps the flat rectangle around a sphere and hands you drag-to-look controls. When either is absent, you get the flat rectangle, stretched edge to edge.

This is the same tag set Google documents for Photo Sphere images, and the same one Google Maps, Kuula, and VR viewers read. It is a standard, not a Facebook quirk — which is why a file fixed for Facebook usually starts working everywhere else too.

Why did my photo lose its 360 tags?

In my experience there are four usual suspects, and they cover almost every "it worked from the camera but not from my edit" story:

The render never had them. Blender, Unreal, and most AI image generators output pixels, not PhotoSphere metadata. A render straight out of Cycles or an AI tool is a beautiful equirectangular image with no instruction attached telling any viewer what to do with it.

The editor stripped them. Photoshop and Lightroom rebuild the JPEG container when you export. Unless the export path explicitly preserves XMP, the GPano block is the first thing to go — the pixels survive, the instructions do not. "Save for web" style exports are repeat offenders here.

A compressor or converter rebuilt the file. Anything that decodes the JPEG and re-encodes it — a bulk optimizer, a format converter, a phone gallery's "save a copy" — produces a fresh container. Fresh containers carry no XMP unless the tool deliberately copies it over.

The file is not a JPEG at all. A PNG or WebP can hold the same 2:1 equirectangular pixels, but Facebook's 360 handling keys off the JPEG+XMP combination. Uploading a PNG of a panorama and expecting it to spin is asking the uploader to read a label that was never printed on that format.

One more distinction worth making: a phone's panorama mode is not a 360 photo. It covers a wide strip, not the full sphere, so even with metadata it only pans left and right. If your image is not a full 2:1 equirectangular — twice as wide as it is tall, covering 360 degrees around and 180 top to bottom — no tag will turn it into a sphere.

What exactly does the GPano block contain?

The block is small. Google's Photo Sphere specification defines the fields below; for a standard full panorama, the pixel numbers are just your image's own dimensions.

Field	What it says	Example for a 4096×2048 image
`GPano:ProjectionType`	How to wrap the image	`equirectangular` (the only value Google products support)
`GPano:UsePanoramaViewer`	Open this in a sphere viewer, not as a flat image	`True`
`GPano:FullPanoWidthPixels` / `FullPanoHeightPixels`	Size of the complete sphere	`4096` / `2048`
`GPano:CroppedAreaImageWidthPixels` / `CroppedAreaImageHeightPixels`	Size of the image actually present	`4096` / `2048`
`GPano:CroppedAreaLeftPixels` / `CroppedAreaTopPixels`	Where the image sits inside the full sphere	`0` / `0`
`GPano:PoseHeadingDegrees`	Compass direction of the image center (needed for Google Maps, optional for Facebook)	`0`

For an uncropped full panorama, the "full pano" and "cropped area" numbers are identical — that is normal, not an error. The cropped-area fields only differ when the image is a partial panorama cut out of a larger sphere, in which case they also carry the offset so the horizon stays level.

How do I check whether my file already has the tags?

Before fixing anything, check. Guessing wastes a re-upload.

If you have ExifTool installed, one command tells you the truth:

exiftool -XMP-GPano:ProjectionType -XMP-GPano:UsePanoramaViewer -XMP-GPano:FullPanoWidthPixels yourphoto.jpg

If ProjectionType comes back equirectangular and the pixel fields match your image size, the file is fine and your problem is elsewhere — most likely the upload itself, or the file was converted to PNG somewhere along the way. If the fields come back empty, you have found your culprit.

No command line? Open the file in any 360 viewer that reads metadata — a browser-based viewer will either wrap it into a sphere or show it flat, which is the same test with less typing.

How do I fix it without re-rendering?

You have two honest options, and neither touches a single pixel.

Option 1: ExifTool. This is the free, no-upload route for people comfortable with a terminal. Set the projection, the viewer flag, and the pixel dimensions to match your actual image:

exiftool -XMP-GPano:ProjectionType="equirectangular" -XMP-GPano:UsePanoramaViewer="True" -XMP-GPano:FullPanoWidthPixels=4096 -XMP-GPano:FullPanoHeightPixels=2048 -XMP-GPano:CroppedAreaImageWidthPixels=4096 -XMP-GPano:CroppedAreaImageHeightPixels=2048 yourphoto.jpg

Change the numbers to your image's real width and height. Wrong numbers here are worse than missing tags — a viewer that trusts bad dimensions will wrap the sphere with a visible pinch at the poles. Then upload the tagged JPEG to Facebook as a new post.

Option 2: a browser injector. Disclosure: I built one of these — the metadata injector in 360 Panorama Viewer (360panoramaviewer.com), which writes the same GPano block into the JPEG header in your browser without uploading the file. Drop in a 2:1 equirectangular JPEG, download the tagged copy, post that. The reason I mention it second is simple: ExifTool does the same job and costs nothing, and if you already have it installed, use it. The injector exists for the people who do not want a terminal involved in posting a photo.

Either way, the workflow after tagging is the same: upload the tagged JPEG as a new Facebook post, and check the preview before publishing. A recognized file shows drag-to-look controls in the preview. If the preview is still flat, do not publish and hope — the file that goes up is the file people see.

What if it still shows flat after the fix?

Run this checklist in order, because the failure is almost always one of these:

Is the uploaded file actually the tagged copy? The classic mistake is tagging photo-fixed.jpg and then uploading the original photo.jpg from the downloads folder out of habit.
Is it a JPEG? A tagged PNG is still a PNG. Convert to JPEG first, then tag, then upload — in that order, since converting after tagging strips the tags again.
Is it really 2:1? Divide width by height. A 6000×3000 render is fine; a 6000×2800 crop is not a full sphere, and no metadata will make Facebook treat it as one.
Did anything compress it after tagging? Messaging the file to yourself, or running it through an optimizer, can rebuild the container. Tag last, upload next, nothing in between.
Did you test the preview? If the preview drags, the post will too. If it does not, the file is still wrong — go back to the ExifTool check rather than re-uploading the same file and hoping for a different result.

That last point is the one I see people skip most. Re-uploading an unchanged file is not troubleshooting; it is the same test with the same answer.

The one-sentence version

Facebook shows your 360 photo flat because the JPEG is missing its PhotoSphere XMP tags — inject GPano:ProjectionType=equirectangular and the matching pixel fields, keep the file a JPEG, and upload the tagged copy as a new post.

If you want to check a file before you post it, the injector page linked above reads the same fields it writes. And if you would rather not trust any tool, the ExifTool commands in this article are the whole fix — no account, no upload, no re-render.

Disclosure: I'm the developer of 360 Panorama Viewer (360panoramaviewer.com), a free browser-based 360 studio. The fix in this article works with any tool that writes standard PhotoSphere XMP, including ExifTool — the tags are Google's open specification, not anything proprietary to my site.

Sources: Google's Photo Sphere XMP metadata specification (developers.google.com); the 360 metadata injector reference at 360panoramaviewer.com/360-metadata-injector/

DEV Community: Han Zhe

Before You Say Just My Socks Is Slow, Check These Three Things

1. You're probably on the wrong node

2. Test all three networks, not just your own

3. Your routing rules may be wasting the good nodes

A five-minute checklist

Why Facebook Shows Your 360 Photo Flat: PhotoSphere XMP, Explained and Fixed

Why Facebook Shows Your 360 Photo Flat: PhotoSphere XMP, Explained and Fixed

How does Facebook decide a photo is 360?

Why did my photo lose its 360 tags?

What exactly does the GPano block contain?

How do I check whether my file already has the tags?

How do I fix it without re-rendering?

What if it still shows flat after the fix?

The one-sentence version