Instaparser: что это за бот Instapaper и нужно ли его блокировать

Instaparser — сервис автоматического получения и разбора веб-контента, созданный командой Instapaper. Его основная задача — получить конкретную веб-страницу и преобразовать её содержимое в структурированный формат, удобный для чтения, приложений, автоматизации и последующей обработки.

Официальный сайт Instaparser предлагает API для трёх основных сценариев:

• извлечение статьи из URL;
• разбор PDF;
• создание краткого summary веб-страницы.

Instaparser построен на parsing engine, который используется Instapaper и развивался на протяжении многих лет обработки веб-статей.

В access.log такой автоматизированный клиент может определяться по User-Agent:

Instaparser/1.0

Cloudflare Bot Directory фиксирует этот UA вместе с Instapaper/4.0 и относит связанного Instapaper bot к Verified.

Что делает Instaparser

Instaparser получает URL и возвращает содержимое страницы в более удобном структурированном виде.

Например, официальный Article API способен вернуть:

• заголовок;
• автора;
• дату;
• основной текст;
• изображения;
• excerpt;
• metadata;
• исходный URL.

То есть Instaparser не просто проверяет доступность URL — он пытается понять, какая часть страницы является основным содержимым статьи.

Зачем Instaparser приходит на сайт

Типичный сценарий начинается не с бесконечного самостоятельного обхода сайта, а с конкретного URL.

Например:

пользователь / приложение
↓
передаёт URL
↓
Instaparser
↓
получает страницу
↓
извлекает основное содержимое
↓
возвращает структурированные данные

Официальный API именно так и работает: клиент передаёт URL статьи, после чего получает структурированный результат.

Поэтому Instaparser правильнее рассматривать как on-demand content fetcher, а не как обычного поискового crawler.

Связь Instaparser и Instapaper

Instaparser напрямую связан с Instapaper.

Официальный сайт говорит, что сервис построен на том же движке, который используется Instapaper для обработки статей. Этот parsing engine развивался на огромном количестве веб-материалов с момента запуска Instapaper.

Для TrafficVeil поэтому логично объединять:

Instapaper
├── Instapaper/4.0
└── Instaparser/1.0

в одно семейство операторов, но сохранять разные технические User-Agent.

Instaparser — это crawler или fetcher

Технически запрос выполняет автоматизированный HTTP-клиент, поэтому в широком смысле его можно называть ботом.

Но функционально точнее:

Content Fetcher / Parser.

Классический crawler обычно:

страница
↓
ссылки
↓
новые страницы
↓
ещё ссылки
↓
массовый crawl

Instaparser API работает иначе:

конкретный URL
↓
fetch
↓
parse
↓
structured content

Такой профиль принципиально важен для поведенческой классификации.

Какие страницы может получать Instaparser

Поскольку URL передаётся сервису пользователем или интеграцией, жёстко фиксированного набора директорий нет.

Нормальными целями могут быть:

• статьи;
• блоги;
• новости;
• публикации;
• документация;
• другие публичные страницы с текстовым содержимым.

Поэтому старое правило «Instaparser обычно сканирует /api/ и весь каталог» не стоит использовать как behavioural fingerprint.

Instaparser может использоваться не только Instapaper

Современный Instaparser доступен как отдельный API для разработчиков.

Официальный продукт предлагает Article Extraction, PDF Extraction и URL Summaries сторонним приложениям. Поэтому запрос к вашему сайту может быть инициирован не только пользователем самого Instapaper, но и приложением, которое использует Instaparser API.

Это означает, что причина визита может быть очень разной:

read-later
content aggregation
news monitoring
link preview
RAG pipeline
summary generation

Эти сценарии прямо приводятся Instaparser как примеры использования API.

Как найти Instaparser в access.log

Базовый поиск:

grep -i "instaparser" /var/log/nginx/access.log

Для семейства Instapaper:

grep -iE "instaparser|instapaper" /var/log/nginx/access.log

Количество запросов:

grep -ic "instaparser" /var/log/nginx/access.log

Топ URL:

grep -i "instaparser" /var/log/nginx/access.log \
| awk '{print $7}' \
| sort \
| uniq -c \
| sort -rn \
| head -30

Топ IP:

grep -i "instaparser" /var/log/nginx/access.log \
| awk '{print $1}' \
| sort \
| uniq -c \
| sort -rn \
| head -30

HTTP-коды:

grep -i "instaparser" /var/log/nginx/access.log \
| awk '{print $9}' \
| sort \
| uniq -c \
| sort -rn

Как выглядит нормальный Instaparser

Почему нельзя доверять только User-Agent

Даже если Cloudflare фиксирует Instaparser как часть Verified Instapaper bot family, сам User-Agent остаётся обычной строкой HTTP-заголовка.

Любой клиент способен отправить:

User-Agent: Instaparser/1.0

Поэтому TrafficVeil не должен использовать:

UA match → unconditional allow

без дополнительных проверок.

Как верифицировать Instaparser

Для более надёжной идентификации TrafficVeil стоит учитывать:

• User-Agent;
• IP;
• ASN;
• ASN organization;
• network type;
• TLS fingerprint;
• HTTP fingerprint;
• набор URL;
• частоту;
• историю источника.

Cloudflare классифицирует Instapaper bot как Verified и отдельно наблюдает Instaparser/1.0, что является сильным внешним сигналом легитимности самого семейства.

Как выглядит spoofed Instaparser

Например:

User-Agent: Instaparser/1.0

GET /.env
GET /.git/config
GET /wp-login.php
GET /backup.zip
GET /phpmyadmin/
GET /vendor/phpunit/

Это не похоже на нормальный content parsing.

TrafficVeil должен оценивать такой источник как:

Instaparser UA spoofing / suspicious automation.

Почему профиль URL особенно важен

Instaparser создан для получения содержимого конкретного URL. Поэтому его normal behavior проще отличать от security scanner.

Создаёт ли Instaparser большую нагрузку

Зависит от того, сколько пользователей или приложений запрашивает ваши URL.

Так как Instaparser API вызывается для конкретных адресов, популярная статья потенциально может получать несколько fetch-запросов от разных сервисных сценариев.

Но оценивать нагрузку нужно не только по hits.

Полезные показатели:

• Requests;
• Unique URLs;
• Unique IP;
• RPS/RPM;
• Bandwidth;
• Average Response Size;
• Cache HIT/MISS;
• Origin Requests;
• TTFB.

Почему CDN может почти полностью убрать стоимость таких запросов

Если публичная статья хорошо кэшируется:

Instaparser
↓
TrafficVeil/CDN cache
↓
HIT

запрос может вообще не дойти до origin.

Поэтому даже заметное число Instaparser hits не обязательно означает заметную CPU-нагрузку.

Стоит ли применять Rate Limit

Если подтверждённый Instaparser создаёт больше запросов, чем требуется сайту, Rate Limit может быть разумным компромиссом.

Но сначала стоит проверить:

1. какие URL запрашиваются;
2. есть ли cache;
3. действительно ли источник похож на Instaparser;
4. какова нагрузка на origin;
5. не происходит ли spoofing UA.

robots.txt для Instaparser

Cloudflare Bot Directory показывает robots.txt-пример для семейства Instapaper и подтверждает существование UA Instaparser/1.0.

Если владелец сайта хочет объявить отдельный запрет:

User-agent: Instaparser
Disallow: /

Можно также учитывать связанный Instapaper UA отдельно:

User-agent: Instapaper
Disallow: /

После изменения желательно проверить фактическую реакцию по access.log.

Частичное ограничение

User-agent: Instaparser
Disallow: /account/
Disallow: /checkout/
Disallow: /admin/
Disallow: /internal/
Allow: /blog/
Allow: /news/

Но robots.txt не является системой авторизации. Закрытые URL должны быть защищены серверными механизмами независимо от поведения Instaparser.

Блокировка через Nginx

if ($http_user_agent ~* "Instaparser") {
    return 403;
}

Это жёсткий фильтр по UA и не доказывает происхождение клиента.

Блокировка через Apache

RewriteEngine On
RewriteCond %{HTTP_USER_AGENT} Instaparser [NC]
RewriteRule ^ - [F,L]

Что произойдёт после блокировки

На Google Search точечная блокировка Instaparser напрямую не влияет: это не Googlebot.

Но функции, которым нужно получить страницу через Instaparser или Instapaper, могут перестать корректно работать.

Это может затронуть сценарии:

• save-to-read-later;
• article extraction;
• content aggregation;
• link previews;
• URL summaries;
• приложения, использующие Instaparser API.

Официальный Instaparser прямо позиционируется для подобных сценариев.

Instaparser не является поисковым ботом

Его не стоит помещать в одну категорию с:

Googlebot
Bingbot
YandexBot

Более точная структура:

Automated Traffic
→ Content Fetchers
→ Read-later & Parsing
→ Instapaper / Instaparser

Как учитывать Instaparser в аналитике

Его запросы не являются человеческими посещениями.

TrafficVeil стоит:

• исключать их из Human Traffic;
• не считать конверсией;
• не относить к Malicious Bots при подтверждённой идентичности;
• учитывать отдельно как Content Fetcher;
• показывать Top URLs;
• показывать Origin Impact;
• отслеживать spoofing.

С кем не путать Instaparser

Рекомендуемая карточка TrafficVeil

Стратегия Allow / Monitor / Rate Limit / Block

Что показывать пользователю TrafficVeil

Вместо общего:

«Неизвестный легитимный сервис. Решение зависит от пользы.»

лучше написать:

Instaparser — сервис команды Instapaper для получения и структурированного разбора веб-страниц. Он используется в read-later, article extraction, content aggregation и других сценариях. Это не поисковый crawler. При нормальном поведении рекомендуем Allow или Monitor.

Итог

Instaparser — не неизвестный crawler. Это официальный сервис команды Instapaper для получения и структурированного разбора веб-контента. Instaparser позволяет разработчикам передать URL статьи и получить очищенный title, author, text, images и metadata, а также предлагает PDF parsing и URL summaries.

Cloudflare Bot Directory фиксирует Instaparser/1.0 в составе Verified Instapaper bot family наряду с Instapaper/4.0.

Поэтому TrafficVeil лучше перенести его из категории «Прочие краулеры и сервисы» в более точную категорию Content Fetchers / Read-later & Parsing.

Базовая политика — Allow / Monitor. Если запросы создают лишнюю нагрузку, стоит сначала проверить cache и реальный Origin Impact. Если же под UA Instaparser начинается vulnerability scanning или хаотичный массовый обход, источник нужно классифицировать по фактическому поведению и блокировать как spoofing.