English is currently available.
Cellular, GSM & LTE DISCUSSION
My SIM800 module registers (+CREG: 0,1) and the signal is around 18, but AT+SAPBR=1,1 often returns ERROR, and when the bearer does open, AT+HTTPACTION=0 gives +HTTPACTION: 0,601,0 or 603 instead of 200. The same server works from a browser.
What is the correct order of commands for an HTTP GET on this module, and how do I tell whether the failure is the APN, the network or the server?
The HTTP service on the SIM800 needs a bearer profile first. The order is: AT+SAPBR=3,1,"Contype","GPRS", AT+SAPBR=3,1,"APN","your.apn", then AT+SAPBR=1,1 to open it and AT+SAPBR=2,1 to query it, which should show an IP address other than 0.0.0.0. After that: AT+HTTPINIT, AT+HTTPPARA="CID",1, AT+HTTPPARA="URL","your-server/path", AT+HTTPACTION=0, wait for the +HTTPACTION line, AT+HTTPREAD, and finally AT+HTTPTERM.
AT+SAPBR=1,1 returns ERROR if the bearer is already open from an earlier run, so query with AT+SAPBR=2,1 first, or close it with AT+SAPBR=0,1 before reopening.
The numbers in +HTTPACTION: 0,601,0 are method, status and data length. Codes from 100 to 599 are real HTTP status codes from the server. The 600 range is generated by the module: 601 is a network error, 603 is a DNS failure and 604 means the stack is busy. So 601 and 603 say that the request never reached your server; do not look at the server logs yet. A signal of 18 is about -77 dBm, which is fine, so coverage is not the cause either.
Both codes usually come from the data connection not being truly up: a wrong APN, a bearer opened before the module attached to packet service, or a SIM without an active data plan. Check that AT+CGATT? returns 1 before opening the bearer, and wait for registration on AT+CGREG?, not only AT+CREG?.
The APN deserves a careful look, because a wrong one fails in confusing ways. Some networks accept any APN string, some give you a context with no route to the internet, and IoT SIMs often need a specific APN, sometimes with a user name and password, which are set with the "USER" and "PWD" parameters of AT+SAPBR=3,1. Take the values from the SIM provider's documentation, not from a phone-settings list for a different plan.
Also test with plain TCP to separate DNS from routing: open a connection to a known numeric IP address and port with the module's TCP commands. If a numeric address works and a host name does not, the problem is DNS; if neither works, it is the bearer or the subscription.
If the server redirects to HTTPS or requires it, that is a separate obstacle. The SIM800's built-in TLS support depends on the firmware version, and older firmware offers only old protocol versions and cipher suites that many current servers refuse, so the handshake fails even though everything up to TCP is fine. A site loading in a browser tells you nothing about this, because the browser negotiates modern TLS.
The options are: update the module firmware if the vendor offers a newer one and check what it supports; run TLS on the microcontroller over a plain TCP socket from the modem, if the microcontroller has the memory for it; or send to a gateway you control that forwards over TLS. For new designs where transport security matters, a current LTE module is the better base.
