Сергей П

Тут кеш ни при чем. Когда вы запускаете с одним воркером или просто дев-сервер, то запущен только один процесс. Именно его конфиг вы и апдейтите.
Когда процессов несколько, а вы выполняете апдейт только в одном, то изменение только там и остаётся. Это не кэш. У каждого процесса своя память, а ваши изменения не затрагивают код, только меняют значение переменной в одном из процессов.
Вот и весь секрет.
Ключевая ошибка вот тут у вас в понимании:

использую обновление файла конфигурации, и параметров.

Вы не трогаете файл конфигурации по факту вот тем своим кодом, что привели, но даже если бы вы в этом файле конфигурации что-то поправили и сохранили, то его нужно в каждом процессе перезагрузить. Ну сделать релоад этого модуля, например.
Вообще это не очень хорошая схема динамического обновления конфигурации.
Используйте какой-нибудь механизм pub/sub (подписок на события), чтобы отправить каждому процессу сигнал об изменении конфигурации.
Ещё можно сделать механизм обнаружения изменения конфигурации в файле, чтобы этот механизм постоянно мониторил таймштамп изменения файла и сравнивал с временем своего обновления конфигурации (в памяти). При нестыковке просто перезагружаете конфигурацию. Это будет работать в каждом процессе.
Ну или лучше погуглите готовые решения для этой задачи. Их много существует. Так будет лучше.

И да, тут надо понимать, что пока у вас простой сервер и в нем не много параметров конфигурации, можно легко контролировать каждый параметр и возможные побочные эффекты от его динамического изменения. Но в сложном проекте можно легко потерять из виду какой-то побочный эффект или неявное промежуточное состояние, когда измененный вот так вот параметр конфигурации приведёт к неконсистентности состояния всего процесса.
В таких случаях при обнаружении процессом признаков изменения конфигурации имеет смысл процессу просто самостоятельно завершиться штатно закрыв все свои соединения. Ещё хорошей идеей было бы сделать это через небольшой рандомный интервал времени, чтобы все ваши процессы делали это не одновременно.
gunicorn, кажется, должен просто запускать новые процессы взамен завершившихся, чтобы сохранить нужное их количество. Тут я не уверен, нужно смотреть. Но новые процессы будут запускаться уже с новой конфигурацией, загруженной штатно, обычным и единственным способом. За счет рандомной паузы перед самозавершением процесса вы не получите мгновенного отказа всех серверных процессов.

Автор вопроса не предоставил необходимой информации для ответа на свой вопрос.
Из постановки вопроса не ясна структура сети. Скорее всего ваш компьютер находится за NAT и снаружи не виден под указанным вами IP-адресом. Погуглите как работает NAT и как пробросить порт за его пределы.
Насколько я понял, автор вопроса через какой-то ресурс вроде https://whatismyipaddress.com выяснил свой ip-адрес и думает, что это внешний интерфейс его компьютера.

Так не получится.

Некоторые провайдеры дают белый IP-адрес при подключении через PPP. Но здесь, похоже не тот случай, ведь увтор вопроса обмолвился о локальном IP-адресе типа 172.x.x.x.

Если подклчение происходит через роутер от провайдера и он предоставляет белый ip, то этот ip выделен вашему роутеру. Нужно читать что такое port forwarding, и с помощью него вам удастся захостить ваше веб-приложение.
В случае с NAT я бы порекоменовал арендовать минимальную vds и хостить приложение там, либо пробросить через него порт по ssh на ваш домашний комп.
Или гуглите читайте кучу статей как пробрасывать порты через нат, вот такую, например: https://habr.com/ru/post/279969/

"x.x.x.x" - это невалидный ip-адрес и домена такого не существует.
С чего вы взязли, что проблема в CORS? При GET-запросах CORS не задействуется.

VDS подойдёт точно, не факт, что это будет самый дешевый вариант, но уж точно самый удобный в плане изоляции. Если сайт не слишком нагруженный, то можно в контейнерах поднять и БД и бэк, и nginx, и что там еще потребуется...

<button class="btn btn-primary btn-buy" type="sumbit" name="id" value="1">Купить</button>

Вот так получится.

На всякий случай напомню, что если хотите разместить ваше приложение за доменом вам нужно:
- купить домен у регистратора (простите, но, судя по вопросу, не очевидно, что вы это сделали),
- разместить ваше приложение на машине с белым IP (заказать его у вашего провайдера или арендовать виртуальную машину у какого-нибудь хостера. Можно еще с dyndns повозиться, но это более сложный путь)
- прописать ip вашей машины у доменного хостера добавив A-запись за вашим доменом.
- на вашей машине с белым ip запустить приложение например на 80 порту (если не нужен ssl) и убедиться, что файрволл не не закрывает его.

Однако если вы фласк будете публиковать так напрямую, ничего хорошего из этого не выйдет.
В принципе, с этого момента ваше приложение будет торчать портом наружу и доступно через домен.
Но часто нужно кроме приложения раздавать статику и заворачивать трафик в ssl `(для https). Для этого на машине запускают еще nginx или другой проксирующий веб-сервер. Через него вы и flask можете раздавать по uwsgi.

фласк ничего не меняет, н просто десериализует json, а одинарные кавычки - это строковые литералы в питоне а не json.

всё правильно, с "a" должно создаваться. Вы просто, скорее всего, не нашли его. Он создаётся в текущем каталоге. сделайте обычный print(os.getcwd()) рядом с записью, и увидите путь, где лежит ваш файл.

Но это плохая идея так писать логи. Для этого есть модуль logging. Вот здесь всё очень детально и с примерами изложено.

Добавьте в структуру ответа поле с флагом ошибки и текстовым пояснением.
Обычно это на клиенте показывают как-то так: "Ой, что-то пошло не так, наша группа поддержки уже в курсе и мы делаем всё возможное, чтобы такое не повторялось. Попробуйте повторить эти действия позднее или обратитесь в нашу службу поддержки с вопросом через вот эту форму <ссылка на форму обратной связи>".
Чтобы написанное не было ложью, нужно детально и тщательно залоггировать все обстоятельства, при которых возникла ошибка, вывести уведомление о проблеме на дэш-борд и в почту администрации сайта. По факту исправления проблемы можно написать клиенту в личный кабинет или на почту сообщение с извинениями, благодарностью за найденную проблему и уведомлением, что все исправлено и можно дальше пользоваться сервисом.
Лишних стыдных подробностей о ваших внутренних косяках пользователю знать не нужно, никаких кодов или фраз тоже не требуется составлять для устного обращения пользователя в поддержку. Идеально, если поддержка сразу проасоциирует обращение и проблему через куки и будет в курсе случившегося при первом же обращении. Это выгладит для пользователя как забота и внимание к его проблеме с вашим сервисом.

Там "==", а не присвоение нужно использовать.
Ещё одно подтверждение того, что вам следует почитать туториал, а не бомбить этот ресурс бессмысленными вопросами.

if __name__ == '__main__':
   app.run(debug=True)

Почитайте как устроен HTTP-протокол хотя бы на вики.
Есть http-сервер, который ждёт подключений на свой порт и обрабатывает запросы.
Каждый запрос характеризуется методом (get, post, put, head, и т.д.), адресом (и это отдельный фактор, никак не взаимосвязанный с методом), заголовками (там у нас пожелания клиента о формате ответа, куки всякие, инфа о клиенте), телом (там у нас данные форм post-запросов, просто загружаемые файлы вроде аватарки или json'а...).
Каждый такой запрос получает сервер и даёт на него какой-то ответ или даже может проигнорировать закрыв или не закрыв соединение.

Написать post-запрос - это, как следует понимать, написать код для выполнения post-запроса (от клиента к серверу, конечно же, иначе не бывает).
Если сервер по данному адресу или по другим каким-то причинам не принимает post-запрос, то вы не сможете со стороны клиента заставить его сделать это.
Даже если будете бить палкой.
Сервер вам будет отвечать ошибкой с каким-то кодом. Если разработчики сервера молодцы, то код ошибки будет релевантен ситуации, а вообще там nt[ybxtcrb может быть что угодно, хоть 666 Devil request success.

Вы не показали здесь исходники сервера, не показали пример кода, который у вас используется, не понимаете даже близко как работает протокол HTTP, не понимаете что спрашиваете...
Как вы вообще ожидаете понять что вам отвечают?
Facepalm.